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:

       Additional NEMO Web Page

Last Modified: 2003-07-29

TJ Kniveton <tj@kniveton.com>
Thierry Ernst <ernst@sfc.wide.ad.jp>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <mrw@windriver.com>
Internet Area Advisor:
Margaret Wasserman <mrw@windriver.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

- 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:
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-01.txt
  • - draft-ietf-nemo-terminology-00.txt
  • - draft-ietf-nemo-basic-support-00.txt
  • No Request For Comments

    Current Meeting Report

    IETF57 Network Mobility (NEMO) Working Group Minutes - July 16, 2003
    Working Group Chairs: Thierry Ernst, T.J. Kniveton
    Minutes by T.J. Kniveton <tj@kniveton.com>
    Thanks to note-taker Karim El-Malki.
    Wednesday July 16th 13:00-15:00; Vienna, Austria.
    1) Brief intro and  Agenda Bashing - TJ
     - No comments on agenda.
    2) NEMO status and milestones - TJ
     - Charter updated at beginning of year
     - Review - do some milestones need updates?
     - Will wait until terminology, requirements, and basic solution are done 
    and submit all three together
     - More discussion necessary on security analysis after basic support 
    draft complete
     - Need to identify someone who can work on MIB for basic support
    3) NEMO Basic Support - Ryuji Wakikawa
     * draft-ietf-nemo-basic-support-00.txt
     - Design team formed at last IETF
     - Initial draft has been submitted
     - Issue list home page at 
     - Ryuji explains slides of how basic support draft works 
      Comments on issues raised:
     * Issue 6
     - How does HA distinguish between implicit mode and dynamic routing 
       - Add an explicit flag to the binding update?
     - Do we need to check the consistency of prefixes between routing 
    protocol and BU signaling?
     Pascal Thubert: It's quite common to have a route advertised from 
    different sources; e.g. OSPF and RIP at the same time. They don't have to 
    talk to each other and check consistency. The router has to decide which 
    route is used.
     - We may be able to accept prefix information by binding update and by 
     Erik Nordmark: If MR is allowed to inject any prefix into routing 
    system, no problem. But if it is authorized to only inject certain 
    prefixes, you need to check, i.e. as part of binding update or rt proto, if 
    it is authorized.
     Ryuji: Do we need to say something in base spec?
     Erik: You might want to point out authorization issue, but not 
    necessarily say how it can be solved.
     Felix Wu: In 6.1, you have a prefix table. The check for the table does the 
    authorization check. So you might want to be more explicit about doing the 
    check there
     Pascal: We mentioned that we could use prefix table to check BUs in 
    explicit mode. For routing protocol, OSPF has its own way of 
    authorizing. We don't expect to change the routing protocols. Is this if we 
    have to introduce a new rt proto
     Felix: If you receive BU from MR, you need to do authorization check to see 
    if the MR really owns this prefix.
     Pascal: Question is if you want to run rt protocol as it exists today. If 
    you have concern, just don't configure routing protocol on the tunnel.
     Erik: If that's the approach the WG wants to take, you should document it, 
    i.e. if you want to run a routing protocol over this, it will inject 
    routes for any prefix. In multihoming case, if you have 2 tunnels in a 
    single routing domain, you only inject one prefix.
     * Issue 3
     - Should HA forward packets for the MNNs to the MR if the R flag was set to 
     - Resolution: no, if R is 0, the MR is only a mobile host.
     - Should HA store prefix info in BCE?
     - Resolution: Yes, in explicit case, useful for deleting prefix route when 
    BCE deleted.
     Chan-wah Ng: In implicit mode, how does the home agent generate the 
    prefix to be stored in bindiing cache?
     Ryuji: In proposed text, we didn't say anything about implicit case. It 
    might limit the implementation too much.
     Pascal: This is being debated now on the mailing list. It's not 
    important what caused MR to inject route, but you must be able to clean it 
    up. In implicit, the MR is not injecting routes, so you don't need this 
     * Issue 5 - presented by Pascal Thubert
     - Chapter 7 needs to be made clearer.
     - We would like to have aggregation of mobile networks that can be 
    advertised without injecting individual prefixes, called Extended Homne 
     - Considered like a pie cut into pieces, with each piece given to a MR
     - EHN can be "the" home network, or you can have it in a virtual 
     - Figure shown on how to bring mobile network home in EHN
     Erik: picture shows /48 assigned to a wire.
     Pascal: This is just an example. You can make home network <=> EHN
     Erik: I don't understand problem. Config you described falls out of how 
    basic support works. If running rt proto, when you move home, run it where 
    you attach.
     Pascal: Want to avoid encapsulation.
     Erik: Assuming you're not running IGP. OK I understand problem.
     - Also intended to keep things open, not to prevent multihoming
     Greg Daley: Arrival home (w/o rt proto) is less likely to occur in most 
    cases. Maybe this could be a separate draft, with options available in base 
     Pascal: Wanted basic to be small, and write side draft if needed. So 
    nothing about multihoming, route optimization, multicast.
     TJ: Design team will issue -01 draft before next IETF, already in 
    4) Multihoming - Chan-Wah Ng
     * draft-ng-nemo-multihoming-issues-01
     - Multihoming issues draft: last IETF suggested more clearly 
    organized multihoming taxonomy, hence the new draft.
     - Julian Charbon and Chan-Wah evaluated basic support for 
    multihoming reqs
     - But it missed draft deadline. URL published on mailing list.
     - 4 Problem categories identified on on mailing list.
     - They have been renamed according to (x,y,z).
       - x is single MR vs. multiple MRs.
       - y is single HA vs. multiple HAs.
       - z is single MNP vs. multiple MNPs.
     * Issue: registration of multiple CoAs
     - More of a MIPv6 problem
     - Addressed by Ryuji's multiple CoA draft in MIP WG
     * Issue: registration of multiple MNPs
     - Support already available in the basic support draft (issue can be 
     Pascal: There is no equivalent of DAD test for MNPs in base draft.
       I.e. two links can believe they're the same prefix. So we have to test 
    regs so we don't have a double registration. With multihoming you want to 
    accept the second registration. So we have to be able to detect the 
     Erik: Desire to have same prefix advertised (explicit or through BUs) at 
    different places, to allow redundancy. But that doesn't mean address of 
    router has to appear in multiple places. HoA -> CoA is 1:1 mapping, but MNP 
    can show up in multiple places.
     * Issue: BU registration to different HAs with same HoA
     - Also MIPv6 specific. Can HA be in different domains?
     - Suggestion on ML not to support case when HAs are in different 
     John _: What happens if home network is multihomed? Does it support HA in 
    different domains?
     Chan-Wah: When home net is multihomed, it is not a NEMO concern.
     Pascal: If you have prefix 1 registered to HA1, you can have prefix2 to 
    register with HA2, so you can stay available.
     John: Connection to prefix1 is broken. Better to have connection 
    through ISP
     Pascal: Just a matter of trust; it's hard to sign a BU for a prefix.
     * Issue: Need for MR to indicate policy preference for different 
    MNPs,CoAs, HoAs
     Felix: If I have 2 MNPs belonging to 2 admin domains (2 HAs), will 
    packet with SRC in MNP1 be sent through HA2?
     Pascal: We should add something about source address selection. 
    Interface selection should choose the address corresponding to that HA.
     Felix: Within mobile net, we use ad-hoc protocol with 2 MRs. The proto has 
    to be defined carefully, or it would go to the wrong MR. Routing would have 
    to consider source address, not just destination addr.
     Erik: Interaction between source addr selection, multihoming not 
    NEMO-specific Outer address has to be topologically significant for 
    ingress, and inner address has to be topologically significant for HA.
     Chan-Wah: Can this be handled by multi6 WG? We can restrict each MNP so it 
    can only be registered to one HA.
     * Issue: Fault Tolerance
     - When egress interface of MR fails, we should have alternate path. But 
    this could be a problem with ingress filtering in the other domain.
     * Eliminating Scenarios
     - (See slides for summary of each case)
     Ryuji: Question on 3rd and 4th case. I gave presentation at MIP WG 
    today. I would like to know if there is functionality missing from our 
    draft for NEMO
     Erik: There is a way of simplifying two bottom ones. Such a MR with 
    multiple tunnels, if it has 2 HoAs, you don't need to do multiple CoA 
    registrations. You can just use two HoAs that are for the same MNP.
     Ryuji: Idea to register multiple CoAs proposed by Pascal first. If MR must 
    have multiple HoAs, for each interface I need different HoAs. If all 
    interf bound to same HoA, we can hide the number of interfaces on MR.
     Erik: If you want to test whether tunnel/interface working, can't use HoA in 
    that case. Not unique.
     - This scenario can be supported by basic NEMO solution be 
    restricting interface to a single HoA, or by using Ryuji's multiple CoA 
     - Conclusion: Basic NEMO support can support these scenarios.
     - Next 4 involve multiple HAs. Can HAs be in different domains?
     - Suggestion to restrict basic NEMO support on multihoming to HAs in same 
     Felix: Another question for (1,1,0). Assuming they belong to same 
    domain, can I announce one prefix to one HA, and a sub-portion of that 
    prefix to another HA?
     Chan-wah: might still have problem of ingress filtering. Let's move it to 
    the list.
     Pascal: With basic, it will be difficult. The EHN is the only thing that 
    leaks out of HAs. It could be configured, but that's not what we had in 
     - Moving forward, question about introducing text for Multiple CoAs and 
     - Preference Indication in BU? MNP preference in RA?
     - Fault Tolerance - devise solution to enable fault tolerance
     - Is WG interested in these?
     Karim: Didn't you say multiple CoAs would be solved in MIPv6?
     Chan-Wah: Multiple prefix registration could cause problem with 
    multiple CoA
     _: We are working on this problem in the multi6 WG.
     TJ: Consensus sounds like this will be solved in multi6 /other groups
     _: Multi6 has taken years to get to nowhere. If you want a solution, move 
    forward. But don't just toss it to multi6 now
     - Preference Indication:
     Erik: Prefixes are tricky because you don't know how to interpret them. You 
    might be able to convey some info, like you have a primary and backup 
    tunnel, i.e. on 802.11 and GPRS. But you have to be careful how it is 
     - We are running out of time, so the rest will be on the list.
     Thierry: Status of multihoming documents: should they be a working group 
       For: approx. 14. Against: 0.
    5) IPR Issues - T.J. Kniveton
     - Companies participating in IETF process are required to inform WGs 
    about IPR
     - Status of IPR on basic draft: Nokia and Cisco have said there may be IPR 
    related to basic draft.
     - TJ has attempted to clear up licensing position on these
       - Within the last couple of weeks, Nokia has posted an IPR 
    licensing statement for the basic draft on the IETF IPR web page, as has 
     - Nokia has arranged Royalty Free (RF) license for open-source 
     - Cisco has granted Reasonable and Non-Discriminatory (RAND) license, 
    based on reciprocity.
     * Does WG feel that RF is necessary, or is RAND ok?
     - If RF desired, we need to get more information
     George Tsirtis: RF (Nokia) is for open source only. So not even RAND 
     TJ: For non open-source, general patent license applies (RAND) 
    conforming to IETF requirements, as stated in the licensing 
     - Not clear whether Cisco does RF licensing. What does WG wish to do?
     Kent Leung: Nokia and Cisco both have RAND at this point, for 
     Erik: Another possibility is to find out more about Nokia IPR, if people 
    are interested in non-open source implementations. I can also answer 
    general questions. But this is up to the WG to decide how to proceed. Once we 
    know something about the claims from patent published or application or 
    another way, then we have more info about how to proceed. But we have to 
    have well-informed opinions on how to proceed.
     Greg Daley: I had some experience with non-RF licenses in GPL 
    development, and it really stops the development dead for Linux. So 
    further info from Cisco would be good; Nokia is cleared up for GPL.
     Chan-Wah: Important thing is to know which portion of NEMO basic 
    support the IPR covers. Can we have scaled-down version not covered by IPR?
     Erik: If people want to try to find out more, they could ask 
    companies which have submitted notices for more info. But you might not get a 
    response from the lawyers. If people are willing to provide more info, that 
    might be useful for WG. If WG believes RF for open source, or RF in 
    general is critical, then we can send that message to the people holding the 
    IPR, and they might come up with better terms. That has happened in the 
    past in other working groups.
     - Since we are running over time, let's continue this discussion on the 
    6) Threat Analysis - Souhwan Jung
     - Topics:
       - Three-layer threat model
       - Generic threats to NEMO
       - Discussion: What are threats specific to NEMO basic draft?
     * draft-jung-nemo-threat-analysis-00
       - provides a generic approach to protocol threat analysis
     - Example NEMO configuration shown in figure
     - Threats to signaling and data path: MR-HA, MR-MNN, MNN-CN
     - Compromise of MR or HA
     - DoS, Traffic Analysis
     - What are the threat issues to NEMO basic support draft?
       - This draft was written before the basic support draft. Still in 
     * Issue 1: Threat to MR
     - MR is most important entity in NEMO. IPsec protects signaling b/t MR & HA
     - Compromise of MR can cause serious problems in NEMO operation.
     - Correctness of BU is critical. HA must double-check
     John: MN is as important as MR. Is there a serious difference?
     Souhwan: compromise of single node might not be problem, but MR causes 
    problem for every MNN. MN has same problem, but we don't need 
    mechanism for MN.
     Alper Yegin: I agree there is a threat, but in context of NEMO, what 
    should we be looking at? Should we be detecting when MR is 
    compromised? We might be trying to do things not doable with NEMO 
     Souhwan: We did not come up with solution, but maybe something like RR in 
    MIPv6 can show if MR not working correctly.
     Felix: One of the problems with MR being compromised is that he can 
    announce any BU, and suck in other address traffic to this mobile net, if HA 
    does not perform prefix table check as performed in basic solution.
     Alper: Compromise of MR in NEMO is same as compromise of access router in 
    fixed network.
     Hesham Soliman: How are these threats different than threats to any 
    generic host on the Internet? Why is IPsec not enough? Associating HoA with 
    SA is enough. Why is this specific to mobility?
     Souhwan: MR is so important for NEMO operations, we need to 
    doublecheck whether packet is delivered to correct node
     Hesham: Same problem for nodes in Mobile IPv6. Not specific to NEMO.
     * Issue 2: Threat to HA
     * Issue 3: Threat related to multi-homing
     - (This is basically the same issue with address selection and 
    multiple HAs discussed earlier -- see figure in slides)
     - DoS attack may be related to this phenomenon
     - Comments? None.
     * Issue 4: Traffic Analysis
     - Traffic from mobile networks go through bi-directional tunnel. So it is 
    the same as in Mobile IP, but more severe because traffic goes through 
     Hesham: So where is the threat in this?
     Souhwan: DoS attack can be connected to this, if we change the routing 
    mechanism. So routing to MR2 can cause packets to be blocked.
     Hesham: Again, this is not NEMO-specific. In any multihomed site, you need 
    to route things so that packets won't be blocked. There's no NEMO 
    protocol inside the yellow cloud [Mobile Network].
     Pascal: Key thing here is that we wanted NEMO to be a stub network. So we 
    cut routing paths that would end up having HA2's routes to be 
    advertised at HA1.
     Hesham: OK, but we don't do any routing inside mobile network cloud. It's 
    normal routing.
     Alper: I agree with Hesham here. What we are looking at are not 
    NEMO-specific threats, they are general Internet architecture issues with 
    security. What we should be addressing are threats specifically created by 
    NEMO scenarios.
     - Location information of MR may be extracted by traffic analysis.
     - This is also arguable whether this is a specific problem to NEMO.
     Felix: I would like to comment about some of the questions asked 
    earlier regarding what we are doing here is generic to all protocols. It was 
    mentioned that IPsec can be broken or compromised. When we say IPsec is 
    insufficient, it is because it provides confidentiality and 
    authenticity. But it does not provide authorization. But in NEMO, the 
    requirement is for a relationship between MR and HA allowing 
    authorization. So the protocol has to handle this issue in some way. So 
    that particular problem is very NEMO-specific. As for multihoming, it is 
    probably going to be dealt with by Multi6.
    7) Updates of Terminology and Requirements Drafts - Thierry Ernst
     * draft-ietf-nemo-terminology-00
     - Was personal submission first; is now a WG document.
     - General terminology has been moved to SeaMoby terminology draft.
     - May be useful to add new terms related to multihoming. Already a 
    section on multihoming and nested mobile networks.
     - Terms specific to NEMO Basic Support should be defined in Basic 
    Support draft. Perhaps we need to remove/add new terms.
     Pascal: We are using "top-level mobile router". Could you bring the term 
    back from the dead?
     Thierry: Synonym is "root MR". You can use it as well.
     - Would be best to submit this draft at the same time as NEMO Basic 
     * draft-ietf-nemo-requirements-01
     - Title has been slightly changed from NEMO Requirements to NEMO Goals and
       Requirements, because some sections are not mandatory.
       - Section 4 renamed to NEMO Design Goals.
       - Removed MAY and MUST.
       - Section 5 contains the actual requirements for basic support.
     - [Various changes to requirements reviewed; see slides for exact 
     Pascal: on R02, it seems all tunnels must be active at any point in time, 
    which is not really what we want. Maybe the second MR can be a backup.
     Thierry: When we say must set up a bi-directional tunnel, probably 
    doesn't have to be set up all the time. It's tricky.
     - Should we put reference to MIPv6 (R09)under 17? Who doesn't want to 
       - Take it to the list
     - Multihoming (R12) - changed from MUST to SHOULD. 12.1,.2,.3 may not be 
    necessary, because they are contained in terminology. (No comments).
     - NEMO support signaling over tunnel must be minimized - should we bring 
    this requirement back?
     TJ: It's hard to tell what criteria are and whether the requirement has 
    been met, when you say signaling must be minimized.
     - R17 - Please state what protocols are important to be backward 
    compatible with. Please send this information to the mailing list so we 
    know what is important.
     - R18 - Should we put this into the requirements as well?
     Pascal: It seems fair if one egress interface fails, and MR has 2nd 
    interface, that it carries on with that one. Now with two mobile 
    routers, it's hard to detect; it's the same multihoming problem again.
     Thierry: Doesn't mean NEMO basic support must support it, but if we agree 
    it's important, we can work on it. I put it as a SHOULD so if someone 
    wants to work on it.
     Greg Daley: It's a little unclear, because it's talking about "should 
    preserve sessions" as if it's participating in the sessions or has some 
    state. So we should change wording to reflect "should allow sessions to 
    continue uninterrupted" so it's not misleading.
     Thierry: Please propose on mailing list.
    8) Conclusions and Next Steps
     - Basic support draft - we had some good input today
       - There are some remaining issues to resolve
       - -01 draft alpha version is already complete; based on today's issue 
    discussion and mailing list discussion, it will be finished before next 
    IETF meeting
     - Threats analaysis and security considerations discussion needs 
    continued work
       - i.e. which threats are specific to NEMO; guarding against 
    NEMO-specific vs. Mobile IP threats.
     - Identify parties to work on MIB milestone
     - Gather information and get clarification on IPR
       - Develop WG consensus on how to proceed with IPR stakeholders
     - WG meeting today identified multihoming as a working group topic
       - Perhaps add this as a milestone to charter
     Erik: In terms of getting documents finished, it might make sense to be 
    more structured to track issues on mailing list, propose text, and close 
    issues to get them finished 


    NEMO Basic Support Protocol
    NEMO Working Group - Welcome
    Discussion of IPR
    Multihoming Issues
    Threat Analysis for NEMO
    NEMO Terminology and Requirements Updates
    Conclusions and Next Steps