2.3.10 Network Mobility (nemo)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://www.mobilenetworks.org/nemo/ -- Additional NEMO Web Page
NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-05

TJ Kniveton <tj@kniveton.com>
Thierry Ernst <ernst@sfc.wide.ad.jp>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>
Internet Area Advisor:
Margaret Wasserman <margaret@thingmagic.com>
Technical Advisor(s):
Steven Bellovin <smb@research.att.com>
Mailing Lists:
General Discussion: nemo@ietf.org
To Subscribe: nemo-request@ietf.org
Archive: www.ietf.org/mail-archive/working-groups/nemo/current/maillist.html
Description of Working Group:
The NEMO Working Group is concerned with managing the mobility of an entire network, which changes, as a unit, its point of attachment to the Internet and thus its reachability in the topology. The mobile network includes one or more mobile routers (MRs) which connect it to the global Internet.

A mobile network is assumed to be a leaf network, i.e. it will not carry transit traffic. However,it could be multihomed, either with a single MR that has multiple attachments to the internet, or by using multiple MRs that attach the mobile network to the Internet.

Initially,the WG will assume that none of the nodes behind the MR will be aware of the network's mobility, thus the network's movement needs to be completely transparent to the nodes inside the mobile network. This assumption will be made to accomodate nodes inside the network that are not generally aware of mobility.

A basic approach for network mobility support is for each Mobile Router to have a Home Agent, and use bidirectional tunneling between the MR and HA to preserve session continuity while the MR moves. The MR will acquire a Care-of-address from its attachment point much like what is done for Mobile Nodes using Mobile IP. This approach allows nesting of mobile networks, since each MR will appear to its attachment point as a single node.

The WG will take a stepwise approach by standardizing some basic support mechanisms based on the bidirectional tunneling approach, and at the same time study the possible approaches and issues with providing more optimal routing than can be had with (potentially nested) tunneling. However, the WG is not chartered to actually standardize a solution to such route optimization for mobile networks at this point in time.

The WG will work on:

- A threat analysis and security solution for the basic problem (tunneling between HA and MR)

- A solution to the basic problem for both IPv4 and IPv6. The solution will allow all nodes in the mobile network to be reachable via permanent IP addresses, as well as maintain ongoing sessions as the MR changes its point of attachment within the topology. This will be done by maintaining a bidirectional tunnel between the MR and its Home Agent. The WG will investigate reusing the existing Mobile IPv6 mechanisms for the tunnel management, or extend it if deemed necessary.

- An informational document which specifies a detailed problem statement for route optimization and looks at various approaches to solving this problem. This document will look into the issues and tradeoffs involved in making the network's movement visible to some nodes, by optionally making them "NEMO aware". The interaction between route optimization and IP routing will also be described in this document. Furthermore, security considerations for the various approaches will also be considered.

The WG will:

- Ensure that solutions will scale and function for the different mobile network configurations, without requiring changes to Correspondent Nodes in the Internet. All solutions will aim at preserving route aggregation within the Internet and will satisfy an acceptable level of security (a thorough survey of new threats and an analysis of their severity will be conducted)

- Ensure that various mechanisms defined within other IETF WGs will be useful for mobile networks. To achieve this, the NEMO WG will interact with other WGs when needed, and may place requirements on the protocols developed by those WGs.

The WG will not:

- consider routing issues inside the mobile network. Existing routing protocols (including MANET protocols) can be used to solve these problems.

Goals and Milestones:
Mar 03  Submit terminology and requirements documents (for Basic support).
May 03  Submit Threat analysis and security requirements for NEMO.
Aug 03  Submit solution for basic support to IESG.
Nov 03  Submit MIB for Basic support to the IESG.
Mar 04  Submit the analysis of the solution space for route optimization.
Jun 04  Shut down or recharter the WG to solve the route optimization.
  • - draft-ietf-nemo-requirements-02.txt
  • - draft-ietf-nemo-terminology-01.txt
  • - draft-ietf-nemo-basic-support-02.txt
  • No Request For Comments

    Current Meeting Report

    Network Mobility (NEMO) Working Group Minutes
    Monday, March 1st, 9:00-11:30am at IETF 59, Seoul Korea.
    Notes taken by TJ Kniveton and Behcet Saryikaya
    NEMO Working Group chairs: Thierry Ernst, TJ Kniveton
    Working Group supplemental web page: 
    Please see the Meeting Agenda pdf file in the proceedings or at the group 
    web page:
    It contains the agenda of the meeting as held. There is also a video of the 
    entire meeting
    available in the same locations.
    It was not possible to register with Jabber servers or find a Jabber 
    scribe, so no Jabber log is available.
    Agenda bashing - WG Chairs
    no comments
    Working Group Goals and Milestones -- Thierry Ernst
    WG goals and milestones have changed. Two more WG documents. 
    Terminology and Requirements Update - Thierry Ernst
    draft- -terminology-01
    New terms: added Nemo-link, Nemo-enabled MR
    New abbreviation: I-face - ingress interface, E-face - egress 
    Nemo-prefix instead of MNP.
    Deprecated terms: MONET and TLMR (use MR)
    LFN / LMN / VMN: have address taken from Nemo-prefix
    Proposed only MRs may be Nemo-enabled
    Terms from the usage draft. Home link, home network, MRHA tunnel
    Virtual home network
    Are these terms narrow enough?
    Document ready for last call -- any concerns?
    NEMO Requirements
    Updated 2 weeks ago
    Not much to update -- no discussion on mailing list
    Design goals may be enhanced?
    Concern about 1-liner requirements for nemo support
      Apply to basic support specification -- this might not be the proper 
    place for this?
    Thierry solicited feedback. If none, the document will move to IESG soon.
    Basic support draft - TJ Kniveton
    No comments on the list
    Open up question to the list about security discussionHow many people have 
    read latest version of basic support draft? about 30-40.
    Security considerations. Keep this as a separate draft or keep it in the 
    basic support draft? TJ asked input.
    Any implementations of basic support? There was an 
    interoperability test. Went well. 
    TJ concluded that basic support need security analysis details. 
    Multihoming - Nicolas
    Discusses multihoming in general not only for nemo.
    Remove mipv6 specific text and only discuss multi homing in general.
    New I-D. defines multihoming. Goals, real-life scenarios and benefits.
    Ubiquitous access. Redundancy and fault recovery. Redirect the flow on 
    another interface. Load sharing and load balancing. Bi-casting. N-cast to 
    multiple interfaces. Preference settings. 
    Nicolas talke about some real-life scenarios. 
    Analysis: split into two. One interface multiple prefizes. Or several 
    interfaces. If one interface no ubiquitous access.
    Future work. If there is interest. No WG for this work, it could be for new 
    WG, starting with a BOF.
    Thierry asked if people interested in multihoming from the floor, yes 
    there are people interested.
    Erik Nordmark - QoS aspects -- sometimes you want the application to 
    choose. Not really being pursued anywhere.
    Thierry: More opportunity to benefit from Multihoming in NEMO, but some 
    work has to be done in other places
    Hesham Soliman: Good, comprehensive study from systems view. Probably many v6 
    on-link multihoming to IPv6, Multi6 can handle other issues. 
    TJ - maybe authors can identify issues, and which WGs can deal with them, 
    then we can discuss
    Margaret Wasserman - Interesting area, interesting stuff in this draft. 
    Agree w/ Hesham - WGs already working in this space. Should some of this 
    work be taken to those? Does it make sense to form a separate group? Not 
    sure right now, but what do the authors feel is NOT covered at this 
    point, that needs to be done in the IETF?
    Hesham - host multihoming being discussed in MIPv6, and is important for MRs
    Margaret: Host-centric multihoming proposal currently being discussed in 
    Multi6, perhaps in the scope.
    Multihoming problem statement - Chan-wah Ng
    First talked about the change log. Title changed. Then each section was 
    introduced. Sect. 4 has the problem statement. 
    Moving forward. Decide on which scenarios are useful for Nemo. 
    Any feedback from WG on content of the draft?
    Erik N. - would be useful to talk about possible ramifications 
    depending on what the administrative boundaries are. There is some text, but 
    we could use more. What if we multihome to multiple home agents in same or 
    different administrative domain? If they are in different domains, they are 
    likely to get different prefixes.
    CW: that is in the appendix of the draft. 
    Hong-yon Lach: Failure detection is one thing you want to handle. 
    Sometimes, one model might switch to other model (2 MR -> 1 MR). We 
    should make sure that it can handle this kind of shift.
    Mattias Peterson - Isn't the ide to automatically support multiple of 
    TJ - Hong-yon seemed to be commenting that we need to discover what 
    happens when going from 1 -> n or n -> 1
    Margaret: For both of these drafts, what is the difference between 
    generic multihoming issues, and issues directly related to the fact that the 
    network is mobile? We need to look at that harder. The generic issues 
    might not be solved, and we might have to write prob. statements for other 
    working groups to add to this. i.e. what if mobility makes it more 
    advantageous to use some network. What do people think are the real 
    differences in a mobile network?
    Hesham - that's the point we should emphasize to work out -- if it's 
    NEMO-specific, that would be justification to have in this working group. 
    There might be cases where the problem is not specific to NEMO, but more 
    likely to occur in a mobile environment.
    Hesham - (1,1,1) - I don't think it's NEMO specific because if you take out 
    MNNs, you still have the same problem you have to solve for the mobile 
    Ralph Droms - (N,1,1) - in this slide and the next, how do the MRs have the 
    single prefix that's assigned to the mobile link? How is it 
    Ralph - (N,1,N) - the MNNs also have to pick the prefix they want to use. 
    TJ - well this is a mobility-generic problem of address selection.
    Thierry - Are all the scenarios here useful?
    Should we consider all 8 scenarios? 4 people raised their hands
    No? also 4-5 people.
    Erik - having mult prefix with only 1 MR and 1 HA doesn't seem useful. We 
    could have 2 tunnels over different interfaces from MR, which gives 
    redundancy Even with multiple MRs and single prefix, you need to 
    associate the prefixes with multiple CoAs.
    Jung - ? University, Korea. (N,1,1) 2 different MRs and 2 MR may have 
    wireless PAN, other may have GPRS. How can these 2 devices talk over this 
    Chan-wah - you have wireless PAN with 2 routers using this protocol on 
    ingress interface
    Kent Leung - for supporting (1,1,N), I disagree with Erik - there are some 
    cases to support. All of these cases are good to address, and 
    practically we can prioritize or categorize them, and perhaps weed some 
    Mattias P - I would like the appendix A1 to be the idea from Eric for the 
    ownership model, and it can help us solve many problems.
    Thierry - there was a discussion about this last year and it was decided not 
    to deal with this. You list some important factors, we need to address them 
    Hesham - Having 2 uplinks for MR is irrelevant for 1,1,N scenario. N 
    prefixes does not mean N different uplinks.
    Margaret - Do you have a specific charter item this document would 
    Do you think this merged draft Multihoming Problem Statement should 
    become a WG document to address the charter item? Yes - about 30. No - 
    about 1.
    Multihoming Threats - Seongho Cho
    Terminology. Primary MR, alternative MR. Defined failure cases. Link and MR 
    failures. And Black hole attack.
    Nested tunneling is current fault tolerance mechanism.
    No solution of MR fails
    Link failure. 
    Redirection threats. Solution neighbor MRs pre-authenticated. 
    Replay threats. False binding. Fake MR can make a false binding 
    Replay threats. Register/unregister neighbor MRs.
    Kent - This could be a generic issue - having a MR that failed. HSRP or 
    VRRP could allow session to be maintained for mobile networks. Why 
    wouldn't a generic solution deal with this problem?
    -- There's an assumption that MR has pre-assigned secure association with 
    its home agent.
    Kent - well regardless of the physical mobile router, you can make it 
    transparent as to which one is doing the registration
    Erik - have you looked at what people are doing in SEND? Because that 
    might address the first two scenarios where a bogus MR is trying to 
    redirect traffic. This might apply here.
    Basic support usage - Pascal Thubert
    Version 01 draft. Mipv6 home is a subnet on a physical link. Virtual home 
    Extended home network. Aggregated home network and virtual home network 
    Kent - cons - no HA redundancy for home network prefix?
    Mobile home example configuration. Easier management for IT. Root MRs can be 
    defined. And have nested Nemos. Nested route optimization. No pinball 
    Pascal - specific support protocol between 2 HAs could replace this
    Kent - so a specific type of HA support
    Pascal - yes same as MIPv6, that HAs know each other, etc.
    Pascal talked about mailing list questions. Scope is 
    informational. No fix for virtual network configurations. 
    Title. Could be Nemo home network usages.
    More work needed? This was asked on ML but received no answer. 
    Is there anyone who doesn't still think this should be a WG document?
    -no comments
    Prefix delegation - Ralph Droms
    Two problem delegate prefix from home to MR and local prefixes use for 
    hierarchical Nemo.
    First problem: HA acts as DHCPv6 delegating router MR as RR.
    MR acts as relay agent for MNs. All nodes downstream can be 
    configured using DHCPv6. DHCPv6 prefix delegation technology. 
    Hierarchical Nemo. Like local mobility mgmt model standards based (Nemo + 
    DHCP-PD based LMM
    AR-VL AR for visited link owns an aggregation. AR-Vl is Nemo HA for that 
    This draft addresses nested Nemo route optimization. Privacy between 
    visitors and visited in nested Nemo. Standards based Nemo + DHCP-PD.
    How many people have read this draft? - about 15-20 hands
    Erik - how does routing actually work with this type of 
    hierarchical nemo? You are building 2 separate network - home nw that 
    extends into visited link, and access network that extends into visited 
    link. How do you know how traffic traveling back up goes to which nw.
    Pascal - MR builds privately its own mobile network
    Ralph - yes, 2 different prefixes coming from AR
    Erik - effectively, you're making the MR be multiple virtual routers. You 
    need to re=immplement the same mechanisms in the visited link for VLANs. 
    Must be a virtual router and a virtual DHCP relay.
    Nested Mobile Network Issues - Hosik Cho
    MR has Egress and Ingress interfaces. Nested Nemo. Parent MR child MR.
    Route ad message conflict if MR1 and MR2. Hierarchical MRA solution, put 
    Age field. 3 bits for age. Is this enough? Security problems? 
    RO taxonomy - Hiroyuki Ohnishi
    Types of RO. MR-to-CN
    MIPv6 ro over NEMO.
    VMN-VMN VMN1 HA to VMN 2 HA.
    Nested Nemo. Packets cross all MRÂ’s Has.
    RO and LMM. One solution is use DHCP-PD. 
    RO and multihoming. 1,N,* case. 
    AR selection. 
    Not much feedback from ML. Need more comments. 
    Connectathon Report -- TJ Kniveton
    Connecthaton. Nemo basic support protocol interop tests. KEIO 
    University (Japan), Nautilus Project (Japan) and Nokia (California) 
    implementations were present. Test network comprised 3 HAs, 2MRs. 
    Explicit mode was tested. Implicit was not tested, IPsec MR home 
    registration tested. Tests were successful. This is good for 
    validating the protocol design work being done in this group -- it works.
    Nemo IPR - TJ Kniveton
    New RFC 3669 explaining some IPR issues, I suggest everyone should read.
    Cisco and Nokia have IPR claims. Nokia offered royalty free licensing for 
    open source implementation. TJ reminded group that Cisco has stated they 
    have a no-first-strike policy, meaning that they have never, and do not 
    intend to, ever sue or ask for royalties of IETF related patents, unless it 
    is in defense of someone else suing or asking royalties from them. Same is 
    true for Nokia.
    Not known if there are any pending patents, but people are welcome to 
    search the issued patents and open applications (which includes Nokia's and 
    Cisco's claims), at the US Patent Office, www.uspto.gov (of course this is 
    only for US patents).
    See extensive discussion of this topic from prior meetings and in the IETF 
    IPR working group.
    some Conclusions -- TJ Kniveton
    Nemo status. Basic support draft will continue its 
    standardisation path. Nemo-external security analysis will be done, 
    starting with Bar BOF at this IETF.
    Multihoming. What is difference generic multihoming and Nemo specific 
    Can we identify Nemo work?
    Basic support usages
    Prefix delegation, maybe split into two delegate from HA to MR and MR 
    becomes virtual router and virtual DHCP server.


    NEMO Terminology and Requirements Updates
    NEMO Basic Support Status Update
    Goals and Benefits of Multihoming Generic Issues
    NEMO Multi-homing Issues
    Threats for multi-homed mobile networks
    Basic Nemo Usages
    DHCP - Prefix Delegation for NEMO
    Nested Mobile Network Issues
    Nemo RO taxonomy
    Connectathon NEMO Test Report
    Network Mobility Summary - IETF59