2.3.15 Network Mobility (nemo)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional NEMO Web Page

Last Modified: 2004-10-01


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: http://www.ietf.org/mail-archive/web/nemo/index.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

- 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

Goals and Milestones:

Done  Submit terminology and requirements documents (for Basic support).
Done  Submit NEMO Basic Support to IESG
Done  Submit WG draft -00 on Threat Analysis and Security Requirements for NEMO.
Done  Submit WG draft -00 on Multihoming Problem Statement
Done  Submit WG draft -00 on NEMO Basic Support Usages
Apr 04  Submit Terminology as Informational to IESG
Apr 04  Submit Goals and Requirements as Informational to IESG
Apr 04  Submit WG draft -00 on Prefix Delegation for NEMO
May 04  Submit WG draft -00 on MIB for NEMO Basic Support
Jun 04  Submit WG draft -00 on Analysis of the Solution Space for Route Optimization
Aug 04  Shut down or recharter the WG to solve route optimization


  • draft-ietf-nemo-requirements-03.txt
  • draft-ietf-nemo-terminology-02.txt
  • draft-ietf-nemo-basic-support-03.txt
  • draft-ietf-nemo-home-network-models-01.txt
  • draft-ietf-nemo-multihoming-issues-01.txt
  • draft-ietf-nemo-mib-00.txt

    No Request For Comments

    Current Meeting Report

    NEMO Working Group - IETF 61

    Wednesday, November 10, 2004
    Scribes: Marcelo Bagnulo, Masafumi Watari
    Jabber scribes: T.J. Kniveton, Alexandru Petrescu


    1. Agenda, welcoming, etc .....................................05mins

    2. NEMO WG Status............................................. 05mins

    Terminology and Requirements
    Draft Issues: http://www.sfc.wide.ad.jp/~ernst/nemo

    NEMO Home Network Model

    IPRs on NEMO Basic Support

    3. NEMO Basic Support (draft status).......................... 20mins
    Vijay Devarapalli

    Draft Issues: http://people.nokia.net/vijayd/nemo/issues.html

    4 NEMO MIB Design ........................................... 05mins
    Sri Gundavelli

    "NEMO Management Information Base"

    5. Announcement: 6th TAHI interop test event ................. 05mins
    Yukiyo Akisada

    6. Prefix Delegation ......................................... 10mins
    TJ Kniveton


    7. NEMO Multihoming Issues ................................... 25mins

    "Analysis of Multihoming in Network Mobility Support"
    Draft Issues: http://www.mobilenetworks.org/nemo/draft-ietf-nemo-
    ChanWah Ng (10mins)

    Discussion (5mins)

    "Global HAHA"
    Pascal Thubert (10mins)

    8. NEMO RO Problem Statement ................................. 30mins

    "NEMO Route Optimization Problem Statement"
    Thomas Clausen / Ryuji Wakikawa (5mins)

    "RO with Nested CNs"
    Masafumi Watari / Thierry Ernst (5mins)

    "Update of "Taxonomy of RO models in the NEMO context"
    Pascal Thubert / ChanWah NG (5mins)

    "NEMO RO Pb Statement, Requirements and Evaluation Considerations"
    Fan Zhao (5mins)

    Discussion (10mins)

    9. Securing Prefix in Binding Updates ......................... 05mins
    ChanWah NG

    "Extending Return Routability Procedure for Network Prefix (RRNP)"

    1. Agenda

    No comments about the agenda

    2. NEMO WG Status - Thierry Ernst

    Terminology and Requirements
    Draft Issues: http://www.sfc.wide.ad.jp/~ernst/nemo

    The drafts have been updated a few weeks ago.
    There are still some open issues in the Terminology draft
    Few open issues in the Requirements draft, TJ will update it.
    The goal is to submit it to the IESG as soon as possible.

    NEMO Home Network Model

    Ready for WGLC that will be issued in a couple of days

    IPRs on NEMO Basic Support
    Cisco has changed IPR
    Cisco new statemant: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=497
    Cisco old statement: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=135
    Nokia IPR
    Nokia statement: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=136

    The new IPR statement from Cisco is easier to interpretate, and facilitates open source code developers to implement the NEMO basic support.
    With this changes, Cisco IPR is easier to deal with than the Nokia IPR
    KAME and USAGI are likely to support NEMO after the new IPR.

    C. Ng: The Threats and Analysis draft has not been updated for while, but this is still a milestone on the wg charter, will those be adopted as wg items?
    Thierry and T.J.: If there is no additional threats, we should remove the milestone from the charter. This part is now covered with the NEMO Basic Support update.

    3. NEMO Basic Support (draft status).......................... 20mins
    Vijay Devarapalli

    Draft Issues: http://people.nokia.net/vijayd/nemo/issues.html

    - IANA assignments are done
    - Very close to AUTH48 call
    - Some issues raised recently by Erik Nordamrk
    - The question is why changes need/can be done now and which ones can be made later.

    The proposed classification for changes is:
    - Critical changes that imply a fundamental problem in the document and would require a new WGLC
    - Important changes where the text is not clear and may affect interoperability. these changes can be done if there is wg consensus and the IESG approves them
    - Desirable changes that imply clarifications. These can be done in this document or can be done in future versions
    - Minor changes mostly editorial, that can be done now since they don't affect the protocol.

    The proposed changes since IESG approval have been discussed on the WG ML
    The Draft Issues are at:

    The changes have been classified in the above categories as following:

    * Critical changes

    * Important changes
    Issue 42
    The question is whether to include all the prefix in BU.
    The consensus in the discussion in the ML was to include all the prefixes in a BU

    BA status values
    MR discards BAck with status values 141 and 142 in implicit mode
    Status value 143 makes no sense in explicit mode.
    These would only occur in these modes if there is a misconfiguration. However, the current text says to silently discard. Then, the MR user wouldn't know what is happening without an error.
    The proposed solution is to treat this as a fatal error.
    This solution does not require any changes on the wire, it is mostly an implementation hint.

    The use of tunnel encapsulation limit
    There is text to limit the number of nested mobile routers.
    However, this is not possible, or would require a complicated solution.
    The proposed solution is to remove that paragraph.

    Issue 39
    Conflicting wording of SHOULD and MUST
    The proposed solution is to use SHOULD
    Another issue to explicitly list authorization of the MR in the security considerations section
    The solution was to add text to security considerations section
    Another issue is to clarify text about error code 143 in
    BAck, without changing IANA considerations.
    Another issue is about sending routing updates on the visited link
    This can't be enforced. This was spotted by Alex Z. before the IESG last call, but mistakenly not updated in the doc.

    * Other changes that fall under the other categories refer to the above URL of the issues list

    - No critical changes
    - Few changes are needed
    - Authors recommendation: only accept changed don't require recycling the doc to the WG
    - IESG members should be made aware of the changes
    - Do the changes during AUTH48


    Pascal: Which is the impact on existing implementations of these changes?
    No comments were made about this
    Thierry: Sense of the room: Is is a good idea to submit the draft or we should remove it from RFC queue?
    Hands for shipping the document ASAP: some hands
    Hands for retaining the document: none
    TJ: Is this classification of the changes is good approach? The proposal is to make important and minor changes now and defer the intermediate, any comments or objections? none

    4 NEMO MIB Design ........................................... 05mins
    Sri Gundavelli

    "NEMO Management Information Base"

    The MIPv6 mib was published and it manages the MIPv6 part.
    The focus here is NEMO as the managed entity
    The NEMO mib structure has 4 groups
    - nemoSystem Group: Provides general information relevant to the implementation and operation of the NEMO protocol
    - nemoStats Group: statistics related to the NEMO protocol
    - nemoNotification Group: defines the notification generated by the NEMO entity in response to the operationally interesting protocol state changes
    - nemoConformance Group: identifies the managed objects that needs to be implemented for conforming
    This is the first submission and we expect to include more objects in future releases
    The general question is what additional objects do we need?
    Additional Issues to be determined
    - Need to add the objects for HA
    - What other notification do we need?
    - Do we need other objects for diagnostics?
    What's next?
    - Review the draft based on the WG input
    - Get it reviewed by a MIB Doctor

    5. Announcement: 6th TAHI interop test event ................. 05mins
    Yukiyo Akisada

    See http://www.tahi.org/inop/6thinterop.html
    Test event in Japan, Chiba, 24 Jan (1 week)
    Interop test: NEMO basic support is included
    Conformance test: NEMO is included

    6. Prefix Delegation ......................................... 10mins
    TJ Kniveton


    Prefix delegation is included in the charter of the WG
    This draft is augmenting the work done by R. Droms
    The goal is to use NEMO signaling for prefix delegation
    New protocol elements are defined to carry prefix requests
    Both Transient (CoA) and Persistent (HoA) prefixes are considered
    This approach complements DHCP methods.
    NEMO signaling has some additional mobility related attributes
    and NEMO based approaches might save flows
    Question to the wg is: Is the WG interested in DHCPv6 only method?
    Does it make sense to merge this approach with DHCPv6?


    Vijay: I don't agree with statement that the two approaches are complementary. DHCP can provide a complete solution.
    TJ: You can have a solution with only DHCP, but there are some nemo specifics elements missing. You can also have a solution using only nemo signaling also. So there are three options only NEMO, DHCP, hybrid.
    Vijay: Could we have two proposed methods, where we just have the DHCPv6, and the other with this apporach?
    TJ: We could consider this options. Opinions from the WG?
    Pascal: The motivation part of the draft says clearly why we need this so please read it if you haven't.
    Pascal: Do we need to merge this or separate is fine?
    Vijay: Separate is fine
    TJ: No sense from the room. We proceed working with Ralph and Pascal and figure out how to integrate those, since there is no sense from the room
    Vidya: MIP6 agreed on using NAI for HoA, are we just relying on MIP6 for whatever they decide?
    TJ: NEMO is an extension on MIP6, whatever agreement HA and MN have, they'll be a parallel set of rules for MR
    Vidya: There needs to be a way for authorizing MR say it's acceptable to own this prefix
    TJ: This is an implementation/policy decision, how do we decide MR allowed to use a HoA? The same thing happen with prefixes.
    TJ: In conclusion, since there's really no strong oppinion. We could advance both of these documents (DHCP based and NEMO based) as WG items.
    Ryuji: Both mechanisms are statefull, do we need two statefull mechanisms? Do we need a stateless mechanism?
    Erik: This draft will be a wg but i can't find the draft in id directory
    TJ: It was submitted late and it is not in directory
    TJ: Ralph's draft is expired

    7. NEMO Multihoming Issues ................................... 25mins

    "Analysis of Multihoming in Network Mobility Support"
    Draft Issues: http://www.mobilenetworks.org/nemo/draft-ietf-nemo-multihoming-issues
    ChanWah Ng (10mins)

    Discussion (5mins)

    List of issues and proposed solutions:
    Issue 1: fixed
    Issue 2: rejected
    Issue 3: accept and remove text
    Issue 4: remove the word different
    Issue 5: rejected
    Issue 6: updated benefits lists
    Issue 7: updated description
    Issue 8: explain that it is only an example
    Issue 9: description of the problem
    Issue 10: other failure modes explored
    Issue 11: follow multi6
    How to close 12-13?
    Keep the text as an appendix
    Move to a separate draft
    WG opinions:
    Marcelo: Move it to separete draft
    TJ: Do both. Keep it as an appendix for now and make a new doc if needed.

    Which problems should be solved by NEMO WG
    - Path survival
    - Path selection
    - Ingress filtering
    - Failure Detection
    - Media Detection
    - HA sync
    - Prefix Delegation
    - Multiple Binding Registration
    - Source Address Selection
    - Impact on Routing Infrastructure
    - Nested Mobile Networks
    - Split Mobile Networks


    Pascal: Split mobile network should not happen, or must not happen.
    Marcelo: Path survival may be different in NEMO than in multi6 since on of the goal of NEMO is to support ubiquity. This means that the failure will occur in the access link. It may make sense to optimize this case. In addition, paths in NEMO case may have very different characteristics, so they may be different considerations than in the multi6 case. Finally, in multi6 it is assumed to be multiple prefixes, which may not be the case in NEMO multihoming.
    Pascal: Can we just say wait for multi6?
    TJ: We can't expect other WG to solve items we need that is not addressed in the charter.
    Marcelo: We should identify which can be expected to be covered by multi6 and which needs to be done in NEMO.
    PAscal: My conclusion is I believe some of it may end up here
    TJ: Does everybody agree with the categorization presented here? We should really follow up with this offline

    "Global HAHA"
    Pascal Thubert (10mins)

    The history of the document is that it started as draft-wakikawa-mip6-nemo-haha and then the document split into 3 documents: The Base document for HAHA gives normative part. Then Global HAHA provides distribution of home across internet and the local HAHA which provides high availability in a link.
    In this presentation we will focus on Global HAHA. The NEMO requirements include Multlihoming support and that multiple HA has to be distributed both locally and globally.
    One use case for the global disctributions is the airplane case.
    Among the problems that are being addressed we have the main target is the HA synchronization
    Additionally, we propose to obtain a L3 operation for NEMO
    In both NEMO basic support and MIPv6 Home are anchored to Home Link at L2
    This means that the home can not be distributed geographically
    Then the Home link is a single point of failure
    So NEMO is an hybrid L2-L3 operation
    The proposal is to make NEMO full L3


    Alexandru - Global HAHA implies 2 home agents. So maybe we should have HAHAHAHAHA for multihoming

    8. NEMO RO Problem Statement ................................. 30mins

    "RO with Nested CNs"
    Masafumi Watari / Thierry Ernst (5mins)

    Short presentation on the status of his new Nested CN route optimization draft

    "NEMO Route Optimization Problem Statement"
    Thomas Clausen / Ryuji Wakikawa (5mins)

    The goals of this draft is to consider a MANET solution to
    RO problem statement
    Question to merge with other RO-problem-statements

    Pascal: Perhaps this is too much solution oriented. similar to local mobility management approaches. may be an overkill for some cases where there is only a default route

    "NEMO RO Pb Statement, Requirements and Evaluation Considerations"
    Fan Zhao (5mins)

    Presentation of the draft.
    Several scenarios described
    Scenario 1: CN is in the infrastructure
    Scenario 2: CN is in the NEMO network

    "Update of "Taxonomy of RO models in the NEMO context"
    Pascal Thubert / ChanWah NG (5mins)

    Important changes from initial versions, in particular the problem statement is more clear, the description of the solutions is moved to the appendix


    Thierry: We have 4 drafts about RO. We need to select one wg document candidate. The options would be to use the Taxonomy draft as a base wg document or to start from scratch.
    Alex: Start from scartch
    Thierry: Motivation for this preference?
    Alex: Current problem statement draft is too solution oriented. We need a neutral problem statement that is neutral.
    Thierry: Could you expand on this?
    Alex: For example the tree discovery approach is stated in the draft
    Pascal: This was true for version 0 but this version is new. You should read it
    Thierry: Did you read it?
    Alex: I don't remeber
    Tierry: Could you read the draft again and restate the position in the ml
    Ng: Please read the new version of the draft, since the changes are based in your comments
    Cristophe J.: We need more time to read the drafts, move it to the ml
    Erik: The problem is that the taxonomy is based on the solution space . We need to state the problem and not explore the solution space
    Pascal: There is a huge number of drafts proposed, we can get rid of the detail of the different solutions, but we think it is useful to keep the info about solutions, and pro and cons identified.
    Alex: Who has considered this?, this was not discussed in the ml
    Pascal: We are not only providing a problem statement but also we are also providing history
    Alex: The ml was silent
    Hesham: We are ratholing, if we just want to do the charter item, 3 pages drafts is enough
    Alex: The goal is to understand the problem and not based in a solution
    Hesham: We could simple do a 4 page doc with the problem description
    Thierry: Move the discussion to the ml

    Changes in the agenda:

    - Point 9. Securing Prefix in Binding Updates was not presented
    - A new presentation about v4/v6 transition and mobility by Vijay was presented.

    9. v4/v6 transition and mobility

    The problem that is presented is what the NEMO MR should do when it finds itself on an IPv4 access network. This is related to the discussion on v6ops. One option would be something similar to TEREDO, where NEMO runs over a transition mechanism. We can build mobility mechanisms for the transition tunnel (i.e. when the v4 address changes) and another one for the MR tunnel (v6 address). However, the idea would be to collapse all in one tunnel.


    Sri: When you're traversing v4 network, tunneling will be there. When you collapse with HA it's the same.
    Erik: Are you assuming MR and HA have v4 connectivity with no NAT boxes?
    Vijay: We want to allow NAT
    Erik: You're going to end up having every protocol having NAT support
    Hesham: The problem is that a mobile host ends up in all sorts of access networks. Whether it's a host or router is orthagonal. There are different levels of mobility between host and access network, especially where LMM is being used. there are serious inefficiencies for managing mobility on those two levels. The scope is not bound by nemo or mobile ip for hosts, bit it's a general problem for mobility and transition. So, it would be nice to have a general framework for mobility.
    Henrik L.: I agree with Hesham. A lot of different aspects to transition in combination with mobility. I've authored a draft showing the full field of all these combinations. We shouldn't jump into this barrel from different directions from 3-5 work groups, we need a more generic approach.
    Vijay: Need to disagree. I don't think we can come up with a generic mechanism that can cover all mobility solutions. So we should use v6ops tunneling as much as possible. But if MR is v4/v6 and HA is v4/v6, we don't want a NEMO tunnel inside a transition tunnel
    Henrik: I don't think we disagree. Read the draft.
    Hesham: There are a few drafts. Different solutions for different problems. Get an idea of the problem, then we can talk solutions for next year.
    Pascal: I encourage people to read those drafts. This is more critical to us than v4, because you can't do anything w/o v4
    Thierry: should we take this as a milestone for the WG?

    10. Conclusions and Next Steps ................................. 10mins

    - More comments expected on terminology and requirements for wg last call.
    - WG last call for nemo home nw models in a few days
    - Remove threat analysis from milestones (already done).
    - NEMO basic support: next action to be taken about new issues. It will happen on ML in the next week
    - Prefix delegation: we need to discuss whether we accept 1 or 2 documents as wg document.
    - Multihoming: want to close accepted and rejected issues.
    - RO problem statement: need to discuss whether taxonomy draft will be WG document, or whether we will make a new, shorter document.
    - v4/v6 transition will be discussed on mailing list


    NEMO Basic Support update
    Announcement: 6th TAHI interop test event
    Prefix Delegation
    NEMO NEMO Multihoming Multihoming Issues: Report Status
    Global HAHA
    MANETbased Nested NEMO Route Optimization
    Route Optimization with Nested Correspondent Nodes
    Route Optimization Taxonomy: problem statement, benefits, classification and issues of RO
    NEMO RO Problem Statement and Analysis
    v4/v6 transition and mobility
    Security Concern of Network Prefix