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.

Slides:



Advertisements
Similar presentations
Mobile IP Outline Intro to mobile IP Operation Problems with mobility.
Advertisements

Mobile and Wireless Computing Institute for Computer Science, University of Freiburg Western Australian Interactive Virtual Environments Centre (IVEC)
1 Introduction to Mobile IPv6 IIS5711: Mobile Computing Mobile Computing and Broadband Networking Laboratory CIS, NCTU.
Neighbor Discovery for IPv6 Mangesh Kaushikkar. Overview Introduction Terminology Protocol Overview Message Formats Conceptual Model of a Host.
MIP Extensions: FMIP & HMIP
Transitioning to IPv6 April 15,2005 Presented By: Richard Moore PBS Enterprise Technology.
IP Mobility Support Basic idea of IP mobility management
Network Localized Mobility Management using DHCP
資 管 Lee Lesson 12 IPv6 Mobility. 資 管 Lee Lesson Objectives Components of IPv6 mobility IPv6 mobility messages and options IPv6 mobility data structures.
1 Mobile IP Myungchul Kim Tel:
IPv4 and IPv6 Mobility Support Using MPLS and MP-BGP draft-berzin-malis-mpls-mobility-00 Oleg Berzin, Andy Malis {oleg.berzin,
1 Route Optimization based on ND-Proxy for Mobile Nodes in IPv6 Mobile Networks Jaehoon Jeong, Kyeongjin Lee, Jungsoo Park, Hyoungjun Kim ETRI
Mobile IP Overview: Standard IP Standard IP Evolution of Mobile IP Evolution of Mobile IP How it works How it works Problems Assoc. with it Problems Assoc.
MOBILITY SUPPORT IN IPv6
A Study of Mobile IP Kunal Ganguly Wichita State University CS843 – Distributed Computing.
Transition Mechanisms for Ipv6 Hosts and Routers RFC2893 By Michael Pfeiffer.
IPv6 Mobility David Bush. Correspondent Node Operation DEF: Correspondent node is any node that is trying to communicate with a mobile node. This node.
Mobile IP.
IP Mobility Support Basic idea of IP mobility management o understand the issues of network-layer mobility support in IP network o understand the basic.
Mobile IP Polytechnic University Anthony Scalera Heine Nzumafo Duminda Wickramasinghe Edited by: Malathi Veeraraghavan 12/05/01.
Slide 1, Dr. Wolfgang Böhm, Mobile Internet, © Siemens AG 2001 Dr. Wolfgang Böhm Siemens AG, Mobile Internet Dr. Wolfgang.
Mobile IP Traversal Of NAT Devices By, Vivek Nemarugommula.
Mobile IP Seamless connectivity for mobile computers.
1 Chapter06 Mobile IP. 2 Outline What is the problem at the routing layer when Internet hosts move?! Can the problem be solved? What is the standard solution?
2002 년 2 학기이동인터넷프로토콜 1 Mobile IP:Overview 년 2 학기이동인터넷프로토콜 2 Mobile IP overview Is Mobile IP an official standard? What problems does Mobile IP solve?
1 /160 © NOKIA 2001 MobileIPv6_Workshop2001.PPT / / Tutorial Mobile IPv6 Kan Zhigang Nokia Research Center Beijing, P.R.China
IPv6 Mobility Milo Liu SW2 R&D ZyXEL Communications, Inc.
National Institute Of Science & Technology Mobile IP Jiten Mishra (EC ) [1] MOBILE IP Under the guidance of Mr. N. Srinivasu By Jiten Mishra EC
Mobile IP Most of the slides borrowed from Prof. Sridhar Iyer
Mobile IP Chapter 19. Introduction Mobile IP is designed to allow portable computers to move from one network to another Associated with wireless technologies.
1 Sideseadmed (IRT0040) loeng 5/2010 Avo
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.
1 Notice Contributors grant a free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or other copyrightable material contained.
49th IETF - San Diego - 1 Mobile Networks Support in IPv6 - Draft Update draft-ernst-mobileip-v6-01.txt - Thierry Ernst - MOTOROLA Labs Ludovic Bellier.
Dynamic Management of Multiple Mobile Routers Manabu Tsukada, Thierry Ernst, Ryuji Wakikawa and Koshiro Mitsuya Graduate School of Media and Governance,
1 Route Optimization for Large Scale Network Mobility Assisted by BGP Feriel Mimoune, Farid Nait-Abdesselam, Tarik Taleb and Kazuo Hashimoto GLOBECOM 2007.
Spring 2004 Network Mobility School of Electronics and Information Kyung Hee University Choong Seon HONG
Mobile IP Outline Intro to mobile IP Operation Problems with mobility.
Thierry Ernst - MOTOROLA Labs / INRIA Ludovic Bellier - INRIA project PLANETE Claude Castelluccia - INRIA project PLANETE Hong-Yon Lach - MOTOROLA Labs.
1 Mobility Support in IPv6 (MIPv6) Chun-Chuan Yang Dept. Computer Science & Info. Eng. National Chi Nan University.
Advanced Roaming & Mobility Scenarios in IPv6 Rafal Lukawiecki Strategic Consultant & Director Project Botticelli Ltd in.
Understanding IPv6 Slide: 1 Lesson 12 IPv6 Mobility.
Introduction to Mobile IPv6
Spring 2004 Mobile IP School of Electronics and Information Kyung Hee University Choong Seon HONG
Santhosh Rajathayalan ( ) Senthil Kumar Sevugan ( )
Mobile IP 순천향대학교 정보기술공학부 이 상 정 VoIP 특론 순천향대학교 정보기술공학부 이 상 정 2 References  Tutorial: Mobile IP
Mobile IPv6 and Firewalls: Problem Statement Speaker: Jong-Ru Lin
Ασύρματες και Κινητές Επικοινωνίες Ενότητα # 10: Mobile Network Layer: Mobile IP Διδάσκων: Βασίλειος Σύρης Τμήμα: Πληροφορικής.
Mobile IP Definition: Mobile IP is a standard communication protocol, defined to allow mobile device users to move from one IP network to another while.
An Introduction to Mobile IPv4
Network Mobility (NEMO) Advanced Internet 2004 Fall
2003/3/1856th IETF NEMO WG1 Basic Network Mobility Support draft-wakikawa-nemo-basic-00.txt Ryuji Wakikawa Keisuke Uehara
Mobile IP 순천향대학교 전산학과 문종식
Mobility support in IP v4. Internet Computing (CS-413) 2.
Mobility With IP, implicit assumption that there is no mobility. Addresses -- network part, host part -- so routers determine how to get to correct network.
Mobile IP THE 12 TH MEETING. Mobile IP  Incorporation of mobile users in the network.  Cellular system (e.g., GSM) started with mobility in mind. 
ROUTING MOBILE IP  Motivation  Data transfer  Encapsulation.
RFC 3775 IPv6 Mobility Support
Booting up on the Home Link
Mobile Networking (I) CS 395T - Mobile Computing and Wireless Networks
Thierry Ernst (INRIA and WIDE) Hesham Soliman (Ericsson)
NEMO Basic Support Protocol IETF 60, San Diego
Support for Flow bindings in MIPv6 and NEMO
2002 IPv6 技術巡迴研討會 IPv6 Mobility
Network Virtualization
Unit 3 Mobile IP Network Layer
Mobile IP Outline Homework #4 Solutions Intro to mobile IP Operation
Mobile IP Outline Intro to mobile IP Operation Problems with mobility.
Lecture 4a Mobile IP 1.
Mobile IP Outline Intro to mobile IP Operation Problems with mobility.
Presentation transcript:

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

Requirements – RFC 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.

Requirements – RFC 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 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 – RFC3963

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.

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

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

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

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

Basic Support - Overview 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

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

Basic Support - Overview MRHA src address from Mobile Network reverse-tunnels using IP-in-IP encapsulation CN decapsulates and forward

Basic Support - Overview MRHA 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

Basic Support - Overview MRHA 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”

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 –140Mobile Router Operation not permitted –141Invalid Prefix –142Not Authorized for Prefix –143Forwarding Setup failed (prefixes missing)

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

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

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

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

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

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

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

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

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

Basic Support – HA Operation Mobile Network Prefix Registration –The HA processes the Binding Updates as described in section 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

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

Basic Support – HA Operation 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

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

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

Basic Support – HA Operation 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 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.

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.

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

Home Network - Introduction 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

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

Home Network - Introduction 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

Route Optimization

Multihoming

Applications - Airplanes

Applications - Automobiles

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, 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, Leung, K.,G.Dommety, V.Narayana, A. Petrescu. “IPv4 Network Mobility (NEMO) Basic Support Protocol,” IETF, NEMO Working Group, February 24, C. Perkins, Ed. “RFC 3344: IP Mobility Support for IPv4,” IETF Network Working Group, August, Ernst, T. “Network Mobility Support Goals and Requirements,” NEMO Working Group, Internet-Draft, October 24, Ernst, T.,H-Y. Lach. “Network Mobility Support Terminology,” NEMO Working Group, March 6, Ng, C., F. Zhao, M. Watari, P. Thubert. “Netowrk Mobility Route Optimization Solution Space Analysis,” IETF, NEMO Working Group, Febraruy 10, Ng. C.,F. Zhao, M. Watari, P. Thubert. “Network Mobility Route Optimization Problem Statement,” IETF, NEMO Working Group, December 28, Ng. C., E. Paik, T. Ernst, M. Bagnulo, “Analysis of Multihoming in Network Mobility Support,” IETF, NEMO Working Group, February 23, “Nautilus6 – Network Mobility Website,” Nautilus6, WIDE, April, “Nautilus6 – NEPL Enhancement Website,” November 11, 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

END Thanks