2.3.17 Network Mobility (nemo)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN 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: 2005-01-25


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@cs.columbia.edu>

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-04.txt
  • draft-ietf-nemo-terminology-03.txt
  • draft-ietf-nemo-home-network-models-02.txt
  • draft-ietf-nemo-multihoming-issues-02.txt
  • draft-ietf-nemo-mib-00.txt

    Request For Comments:

    RFC3963 Standard Network Mobility (NEMO) Basic Support Protocol

    Current Meeting Report

    # Network Mobility WG (nemo) Minutes
    # IETF 62 Minneapolis
    # Wednesday, March 9 at 1530-1730 @ SALON D
    # Session chair:
    # Thierry Ernst, WIDE at Keio Universiry <ernst@sfc.wide.ad.jp>

    o Minutes:
    - The following persons should be blamed:
    Primary: Greg Daley Monash University <greg.daley@eng.monash.edu.au>
    Secondary: Masafumi Watari, Keio University <watari@sfc.wide.ad.jp>
    Jabber: TJ Kniveton (TJ), Alexandru Petrescu (AP)
    Final compilation: Thierry Ernst

    - Initials for people involved in the reported discussion:
    Greg Daley (GD).
    Thierry Ernst (TE).
    Vijay Devarapalli (VD)
    ChanWah Ng (CWN)
    Marcelo Bagnuto (MB)
    Ryuji Wakikawa (RW)
    Basavaraj.Patil (BP)
    Vidya Narayanan (VN)
    Kent Leung (KT)
    David Hankins (DH)
    Will Ivancic (WI)
    Andrew Dull (Connexion) (AD)
    Erik Nordmark (EN)
    James Kempf (JAK)
    Suresh Krishnan (SK)

    o Meeting Information
    - Attendees:
    Mcast: no money, no mcast this time
    Jabber: 4+
    - Jabber logs:
    - Audio:
    mp3 at Salon D http://www.ietf.org/audio//ietf622.m3u
    - Slides:
    Meeting material: http://www.mobilenetworks.org/nemo/ietf62/

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

    o Introduction by Thierry Ernst
    - WG document status.
    - Reports from TAHI and Connectathon
    - v4 traversal: Vijay Devarapalli (VD)
    - Multihoming: ChanWah Ng (CWN)
    - NEMO and Multi6: Marcelo Bagnuto (MB)
    - Status of NEMO Route Optimization: (CWN)
    - NEMO Additional WebPage http://www.mobilenetworks.org/nemo
    - Check slides later.
    - Links to issues pages for various documents from this page.

    # 2.a NEMO WG Status................................................15mins

    o WG status reported by Thierry Ernst (see slides)

    o NEMO Basic Support Protocol Specification
    - http://www.ietf.org/rfc/rfc3963.txt

    - RFC3963 Standards Track. Jan 2005.
    - Implementations: available on Linux 2.6 and BSD
    (e.g. see http://www.nautilus6.org/implementation)
    - TE going on additional webpage now.
    - Information about all implementations will be put on mobilenetworks.org.
    Name of Implementation:
    More information
    Would be very useful.

    o NEMO Basic Support MIB
    - http://www.ietf.org/internet-drafts/draft-ietf-nemo-mib-00.txt
    - No updates. Authors should still working

    o NEMO Terminology / NEMO Goals and Requirements
    - http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-03.txt
    - http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-04.txt
    - Issue page: http://www.sfc.wide.ad.jp/~ernst/nemo

    - Check web for issues
    - Would like to ship to IESG ASAP. Already said so many times.
    - Couple of issues need to be resolved.
    - Would like comments from WG on issues marked "VALIDATE" before closing.
    - From issue page:
    click on any issue, have title,discussion, new text.
    - If you don't disagree with change, will have these issues as closed.
    - If no feedback, will close and send to IESG.
    - Nemo Requirements Issues: Some listed on the same page.

    o Prefix Delegation
    - Mobile Network Prefix Delegation [Candidate as WG doc]
    - DHCPv6 Prefix Delegation for NEMO [EXPIRED - Candidate as WG doc]
    - Distributed Prefix-Delegation Scheme for NEMO [Recent Submission]
    - Mobile Network Prefix Delegation extension for Mobile IPv6 [EXPIRED]

    - WG milestone, a prefix delegation document.
    - History:
    2 years ago (last revision, expired)
    newer document based on DHCPv6 (now expired)
    - Alper said optimization remove part and resubmit.
    - Didn't get enough comments on TJ's draft (see mail).
    Concern since last IETF draft was not on the IETF repository
    - On the ML, was asked for acceptance, but not sure about whether it
    was appropriate.
    - Now is the right time to say something.
    - So, draft-droms and draft-tj should be accepted as WG doc.

    # 2.b NEMO Home Network Models..................................... 05mins
    o Related doc:
    - http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-02.txt
    - Issue List:

    o Presentation by Vijay Devarapalli (see slides)
    - Quick update. not many changes. v2 submitted recently to address
    - URL in slides.
    - Few editorial changes.
    - Major issues 2 & 4
    - Currently in all models.
    - MR configures an address from MNP, or Home link.
    - Isse Suggested that Home link, with MNP being separated (??? GD)
    - Resubmit and IESG.

    # 3.Report of TAHI and Connectathon events......................... 10mins

    o Presentation by Ryuji Wakikawa (see slides)
    - Results of the connectathon 2/28-3/4 in San Jose about NEMO implementation
    - 3 Implementation: HUT, WIDE, Nokia
    WIDE Nautilus6/HUT (Linux)
    Nokia Research on IPSO stack.
    - Conformance tools:
    MR test suit from TAHI Project
    TAHI test only supports MR, none for HA currently
    34 conformance test items
    - Interoperability Tests and performance
    Binding Registration
    Tested 3 scenarios, both explicit and implicit mode
    Home Reg, Home Re-reg/Dereg
    Nested Case: MR behind MR works fine
    Multiple HAs on the home link: mix of NEMO HA and MIP6 HA
    reply only contains NEMO HAs.
    Tested Binding Ack status values 141,142,143
    Which are defined for NEMO basic support.
    - Interoperability fine, no bugs in spec found.

    o Discussion:
    - GD: is Usagi/HUT different ?
    - TE: USAGI is working on the kernel side, HUT on userland (MIPL2.0)
    The Linux NEMO implementation (NEPL) is a cooperation between HUT
    and Nautilu6, another WIDE team; it made test / debug of NEPL.
    Implementation is done by HUT.

    # 4. V4 Traversal for NEMO Basic Support........................... 20mins

    o Related document:
    IPv4 Care-of Address Registration

    o Presented by Vijay Devarapalli (see slides)
    - IPv4 traversal for IPv6 mobility protocols.
    - IPv4/IPv6 MR may be supported in a v4 network.
    HA to handle v4 care-of-address. v4/v6 tunnel between HA and MN's
    v4 visited address

    o Issues regarding v4 traversal on NEMO basic:
    - MR might end up on an IPv4 only access network
    - MR treats v4 address os CoA and registers to HA
    - doesn't require a tunnel

    o Issues with using transition tunnels and mobility tunnels
    - Double tunneling with IPv6 over IPv4
    - Movement Transparency on IPv4 acess network
    - tranition tunnel breaks when MR moves
    - Mobility for transition tunnel and NEMO tunnel is needed
    - Security between MR and HA
    v4/v6 header and v6/v6 for NEMO. lots of overhead, really large.
    Movement to the v4 network, MR needs to wait until transition
    tunnels are set up, before signaling.
    Security considerations: no relationship between MR and Transition
    routers, preferred that MR negotiates with HA.

    o Observation:
    - MR is dual-stack, support IPv4 and IPv6
    - HA support IPv4 and IPv6
    - Collapse HA and transition router into the same box
    Discovery of v4 addresses.
    Static config?
    DHAAD when in IPv6 network?

    o Requirements:
    - Establish single tunnel between MR and HA
    NEMO is a tunnel protocol,
    - Support NAT Traversal
    - Support mobility for transition tunnels

    o Solution:
    - Send BU to Home agent's V4 address.
    - BU for registration
    - First Deregistration for v6 and then registration of v4/v6 tunnel.

    o Modification to binding update:
    - Mobile IPv6 CoA deregistration.
    - Mobile IPv4 CoA registration.
    - Also used IPsec to do BU, BA, MPS, MPA
    - SA between IPv4/IPv4 care-of-addresses.
    - NAT traversal: NAT detection using IKEv2.
    - If there's a NAT, use UDP IPv6 in UDP over tunneling.
    - Extension very small.
    - Implementing on Shisa (KAME)
    - Movement detection almost done

    o Presentation over: Discussion
    - GD: About "movement detection on both networks"
    Would you like to give input for DNA ? ;-) laughs
    - RW: Movement detection on v4/v6 very tricky
    DHCP takes a long time, to get an address.
    Still possible to roam to v4/v6 network.
    Possible issues, how to work with DHCP in IPv4 network.
    - ??: how does it wortk if you wish to put v4 to the edge and use
    transition tunnel.
    - RW: Fundamental assumption HA support both v4 and v6
    - Not always a deployment scenario.
    - v6 HA well inside v4.
    - Even in this scenario works fine, need changes
    - RW: there are many scenarios of course, but we need a simple
    solution quickly. Many people starting service with NEMO,
    need a transition mechanism.
    There is no v6 network everywhere, can't wait for infrastructure.
    If NEMO can deal with this issue, then it's much easier
    Running v4 network all way inside v6.
    - VD: Don't run native v4 inside v6 network, set up tunnel with box on edge
    - VD: v6 network inside tunnel.
    - SK: Are you pushing home network all way to the edge?
    - VD: you don't have to put it on the edge. This is 1 possibility
    - VD: No that's only one network [??]
    - ??: Working on a transition with the v4 on the mobile.
    - VD: If the HA doesn't support v4, transition tunnel to v4 on the fixed HA.
    - RW: Most of the HAs support v4, but may not have an address.
    - VN: Collapsing the access to the HA, R U introducing security issues ?
    - RW: require SA between HoA and CoA
    - VN: You may have to do something in the firewall to allow access to
    the HA
    - RW: v6 ha is reachable
    - BP: exposing to what ?
    - VN: HA has a globally reachable IP address
    - BP: You are not hiding the HA from anything.
    Typically the HA is not something you'd put in the DMZ.
    - Something you'd put in the DNS, not really hiding.
    Doesn't really matter, not hiding anything.
    - ??: Fundamental changes not so tightly integrated.
    - RW: only one sub-option, not a big modification,
    - BP: very closely integrated with MIPv6, not really the case.
    I don't think it's necessary
    - RW: take a long time. Much harder than v4 transitioning method
    - BP: don't mention Transition tunnel on the HA, you'll get in a rathole.
    - KL: Most of the debate here is: is this the most typical or most
    common scenario. This is a solution, how you deploy it is a
    different issue. We can't figure this out the ideal solution
    right now. Based on v4, placement of HA becomes an issue.
    Debate or find out, gathering a problem statement to find out
    whether this is a scenario we can solve. If this is the problem,
    this is a good scenario.
    - SK: Instead of two tunnels, one extra header. Applicability means
    that all the tunnel issues become less relevant.
    - Alpesh: any plan solving
    - PS may just expand scope.
    - VD: may need to come up all the scenarios.
    - BP: boil the ocean or work on something solvable? Solve one scenario
    that is most applicable
    - RW: Problem must be quickly solved.
    - KL: Some good thoughts, using something to cover both scenarios,
    enterprise router covers some.
    There is a superset of solutions, which is very pointed.
    If Doors cannot solve this scenario, then this [??]
    There's an alternative way of covering this solution, but there's
    only need for a simple solution.
    Need quick standardization, otherwise deployment is limited.
    - RW: Doors is an alternative way
    - DH:Difficulties with DHCP, was it the lease time?
    - RW: It's the detection time whether v4 or v6 address
    - DH: What is the reasonable time,
    - Depends on whether DHCP is triggered, trigger DHCP whenever
    the link changes.
    Basically MR doesn't care about v4 stuff, it's only v6, so we have
    to modify. Need quick hack.
    - Brijesh Kumar (BK): We don't want to build another transition mechanism
    - GD: Doesn't matter, is transparent to hosts.
    - VD: It's not a transition mechanism, it's for NEMO
    - BK: Who wants to do this now?
    - RW: Vehicle companies.
    - VN: Answer is not zero. Today it may be, but required almost
    immediately. Not far in the future.
    - SK: Think it's a good idea, and have seen another idea similar.
    Have seen Flarion's idea, has pretty much same idea.
    - RW: Haven't seen can you show me?

    o Sense of the room:
    - How many people think this topic is interesting? 30-50
    - How many people think it is appropriate to work in NEMO WG ? 20-30
    Draft presented would be "IPv4 CoA Registration" draft-ryuji-nemo-v4-tunnels
    - How many read: 5-6,
    Invite people to read the draft and comment.

    o Discussion (cont):
    - SK: Draft has applicability to more than NEMO.
    - TE: Which working group?
    - SK: MIP6 ask chairs?
    - BP: applicability (MIP6 chair hat on) possible to do here of in MIP6.
    Doesn't really matter.
    - VN: What happened to miptrans?
    - RW: on list, not any traffic.
    - VN: last IETF draft-soliman-v4v6-mipv4-00.txt presented in 2 working

    # 5. Multihoming Issues............................................. 20mins

    o Related document:
    - Analysis of Multihoming in Network Mobility Support
    - Issue List:
    - Gola:
    Update of the WG draft. The main focus of this slot is to get
    consensus on the new text on identifying which issues to be solved
    by the WG.

    o Presented by ChanWah Ng (see slides)
    - new version -02 submitted.
    - Added recommendation on which WG should address the problems
    identified in sec 4
    - still too coarse, need to define specific issues for NEMO WG,
    either in this meeting or the next.
    - These are the current issues, in brackets need WG to look at problems.
    - These are the MH issues we've noted in the draft. later I'll go into

    - TE: Can you go back to the issues: important.
    Some issues are very general (IPv6) and some are Multi6 or nemo.
    Which are the important issues to solve in NEMO or to solve
    in MIPv6, multi6.

    - MB: about this list, do you want comment on specific points?
    - MB: For Path survival, its probably more important to NEMO is should
    be analyzed deeper.
    There should be section for NEMO-link failure and more generic
    failure link as discussed in multi6.
    - MB: One point that is made very clear in the draft: one of the
    important motivation for NEMO is ubiquity support, different
    access media
    This is a failure mode very specific for NEMO.
    Need a MR/HA mechanism, rather than a generic survival mechanism
    Much more frequent that other errors.
    Access link survivability, to provide optimized support for
    A lot of others are generic multi6.
    - MB: Next issue Ingress filtering: I disagree with the conclusion you
    reach in the draft
    - MB: One important point: what are the motivations for having
    multiple prefixes in the NEMO. IMHO, if not from artificial
    creation, you don't have a NEMO specific issue here.
    MR can handle. Not sure we have something specific for ingress
    - MB: Multiple Egresses to separate ISPs. That's my initial feedback

    - CWN: on the last point, I'll give example with multiple prefixes
    which aren't artificially created.
    - TE: with multiple prefixes, you have a good reason to do it, is this
    what you are saying ?
    - MB: No, better see my presentation.

    o Continue Presentation:
    - CWN: Draft issues (not MH issues), 11 closed 11 open. 9 new issues
    since Washington.
    - Comment that multiple prefixes announced on a visited link.
    Text resolution for issue 1.
    - Issue 15: Source routing approach for overcoming ingress filtering.
    Pointed out more complex issues.
    Rewrite text to reflect issues.
    - Issue 16: Exactly what Marcelo has been saying.
    Discuss text which both agree on.
    - Issue 17: reovery in routing infra.
    Failure in network, can use network to recover.
    Pointed out slow: 180ms, end-to-end may be faster.
    Resolution unclear.
    - Draft issue 18 source address selection impacts fault tolerance
    - Issue 19,
    Suggested remove 4.11, prefix of a nemo may be injected in DFZ,
    since no-one would do it that way.
    - Issue 20,
    Normative and informative references, but this is informational.
    - Issue 21, Applicability of appendix B,
    Added section where it clarifies this.
    - Issue 22:
    Applicability of multi6 to NEMO,
    Raised concerns, but need more analysis before multi6 is applicable.
    MB giving a presentation, based on feedback, can be used to resolve
    the issue.

    o Moving forward:
    - when we know the useful configuratiomn then we can figure out what's
    for NEMO to do (what issues should we work on)
    - TE: any questions or comments?
    - TE: Some interest from specific industries, some have different
    configurations in mind. Good if you could show if you're
    interested in one particular scenario. Aircraft for example
    - AD: Admit not up to date with draft.
    Some of the issues in multi6, not convinced we've determined we
    know how to solve yet generally.
    Good to have these ideas, need to figure out how core
    will do it without worrying about the edge.
    - CWN: Depends on what industry wants? Do they want to wait?
    Do they want NEMO to solve the problem ?
    - AD: How we deploy 6 is orthogonal to how 6 is deployed in the core.
    May be earlier or later than the core.
    Drivers are address space and what methods of mobility meet our needs.
    - WI: multihomed MR, advertisements occuring at the HA, they are sort
    of different problems. Keep that separate.
    - AD: Problem which comes up is the distances between HAs,
    how you do tunneling optimization. Transatlantic at high
    bandwidth is poor. Tunneling twice is going to change the
    way the solution looks like.
    - A lot of the people are looking from a smaller area point of
    view. Smaller regional or geographic area, inside US or Japan.
    The way mobile network work today is that people are moving in
    a small network. So backhaul of network is different that when
    you have a backhaul across an ocean or multiple oceans.
    So tunneling gets worse and worse.
    - WI: Agreed, multiple HAs geodistributed is useful, also need to
    understand peoples needs
    - KL: not sure for Mobile networks support, some are interested in
    solutions which aren't regional, but each solution has limitations.

    - TE: To everyone, please speak about your scenario, and what you need
    for your usage. This will help to decide which configurations and
    thus which issues must be solved in priority.

    # 6. Multihoming: NEMO and Multi6.................................. 10mins

    o Related doc:
    - Application of a multi6 protocol to nemo

    o Presentation by Marcelo Bagnulo (see slides)
    - MB: Relate presentation to AD comment.
    - Goal: to understand in which cases multi6 will NOT solve the problems.
    - After this we can decide what we want to solve or if we want to wait for multi6.
    - Understand what could be the possible application for multi6.
    - Only NEMO basic, not RO.

    o Multi6 basic assumption:
    - multi6 or shim6 solution is far from being defined,
    but consensus on characteristics
    - multihoming -> multiaddressing
    - different ISPs -> different prefixes
    - prefixes of the packet determine path
    - change prefix -> change ISP (rehoming)

    o First case: 1 MNP (*,*,1)
    - Only one prefix announced in the NEMO,
    - multi6 can't help
    - Artificially create prefixes to make multi6 work ?
    - One prefix for mobile router.
    - Is this a regional approach? Links between one or more MR and one
    or more HAs.
    - Need all endpoints in internet to be upgraded to support this local
    - Can modify HA and MRs transparent to packet transfer....

    o 2nd case: 1 HA and multiple prefixes (*,1,n)
    - home network is multihomed.
    - home network has multiple ISPs.
    - in order to benefit from multihoming need multi6.
    - selecting the prefix, this won't select the path between the MR and
    - what can be done in this case: mutliple prefixes to multiple paths,
    ends up in reduced fault tolerance.
    - actually forbidding valid mechanisms in order to tie to a specific
    - create artificial prefixes, if have N prefixes, need many prefixes
    to associate between different paths between MR and HA.
    - this is a big solution for a local problem. Is it overkill?

    3rd case: Multiple Prefixes and Multiple HAs (*,n,n)
    Case a) all HAs are served by same ISPs
    similar to (*,1,n)
    all HAs handle any of the prefixes, this is a distributed HA
    equivalent, no interdomain problems. Probably HA-HA protocol,
    with recovery procedures.

    Case b) each home network dserved by ifferent ISP,
    HA acts as a border router.
    Selecting the prefix selects an ISP, fits within multi6.

    Case c) Hybrid Case.
    Some served by same ISP, some served by different ISP,
    Use both methods. HA-HA.

    o Summary:
    - Only case that could be an application of multi6 is (*,n,n)
    (multiple HA, and multiple Prefixes) each served by distinct ISPs.
    - Other cases: introduce artificial MNPs.

    o Other comment:
    - by Erik Nordmark: pointed out that application of multi6 between MR
    and HA, but we're not sure about the complexity of such a solution.

    o Conclude presentation:
    - TE: Thanks for maintaining the connection between multi6 and nemo

    # 7. Current Status of the NEMO RO Discussion on the ML........... 20mins

    o Related I-Ds:
    - Taxonomy of Route Optimization models in the Nemo Context
    - NEMO Route Optimization Problem Statement and Analysis
    - Route Optimization with Nested Correspondent Nodes
    - NEMO Route Optimisation Problem Statement

    o Presentation by ChanWah (see slides)

    o Current status:
    - current analysis pretty much comply with the charter:
    - dtailed problem statement for RO is done
    - analysis of various approaches
    - analysis of issues and tradeoffs involved
    - interaction between RO and IP routing
    - security considerations for the various approaches:
    - some may need more work?

    o Topic discussed on the ML:
    - should we separate PS from solutions analysis
    - draft should avoid being solution-specific
    - how complete is the document to be on analyis
    - how to classify the entire solution space.
    - Intra-nemo problem: When there's nested NEMO, tree discovery to
    avoid loops may be needed. MANET proposal can be used.
    - Tradeoffs between BU storm/signaling storm. What the effect of RO
    is, compared to delay.
    - Discussion on AAA, within the NEMO network.
    - RR test for network prefixes (see next presentation)

    o Contents of WG draft.
    - Between Authors, reached agreement of what we want in WG draft.
    - PS
    - Analysis of RO approaches
    - Related issues/tradeoffs of RO
    - Appendix? Classification / Evaluation criteria

    o Discussion:
    - JAK: PS and Analysis should be separated.
    - JAK: Does analysis contain security considerations?
    - CWN: Yes
    - TE: Possibly split things ?
    - CWN: Finalize contents of drafts and determine if 1 draft or 2.
    - TE: In which draft do you intend to base the problem statement or taxonomy?
    - CWN: some members want a very short problem statement, one on RO
    analysis for solution space.
    - TE: What is the consensus of authors (all drafts)?
    - CWN: use draft thubert-ro-taxonomy as the base (most mature and complete doc)
    - GD: we should separate problem statement and the analysis
    - JAK: Need threat models not tied to solutions.
    - TE: need to think about potential solutions to clarify the problem
    - JAK: of course but then need to abstract out that into text.
    - TE: Who has read draft-thubert:?
    - TE: Who thinks should be approved as WG document.
    - TE: currently draft-thubert has two sections. We could split it in two
    - WI: Is the question that we'll use it as a basis?

    - TE: 2 parts taxonomy and PS, can be split in 2 and PS as WG document
    and Taxonomy as individual for now.
    - VD: can't we do this in parallel?
    - TE: 2WG documents?
    - VD: yes
    - CWN: What has been said today is that the first part of
    draft-thubert will be used as basis of problem statement?
    - TE: use draft-thubert, split in two, 1 for PS, 1 for taxonomy.
    - TE: let's take this to the ML to make sure of the consensus

    # 8. Security issue of sending prefix-scoped BU to CN ............05mins

    o Related doc:
    - Extending Return Routability Procedure for Network Prefix (RRNP)
    - Purpose of this slot: Raise WG awareness on the inadequacy of RR
    with prefix-scoped BU
    - WG Relevance:
    It is a consideration for the WG when analyzing NEMO-Extended.

    o Presentation by ChanWah (see slides)
    - This presentation was for washington, but didn't have time.
    - In order to achieve NEMO RO, the MR or MN could send BU to CN with
    mobile network prefix option
    - 1. MR-CN Opt: CN can have MNP in Routing table, routes to the MNP
    through the MR's COA/.
    - 2. Infrastructure Opt: MR can send BU with MNP to CR; CR informs MR
    which prefix it manages

    o Security threat 1
    - when BU with MNP option changed en-route by attacker
    - or when normal BU inserted with bogus MNP option.
    - Attacker can use this to launch an attack on the MR
    (CN or CR direct to MR packets not intented to MR)
    - threat can be protected by RR

    o Security threat 2:
    - If MR is malicious, claiming to manage MNPs it doesn't own
    - RR only verifies that the CoA and the HoA colocated, not that the
    CoA, HoA and MNP colocated.
    - threat not protected by RR

    o Extension to the RR procedure.
    - Keygen token by CN, NPK, to random address configured from MNP
    - MR intercepts and use to generate binding management key

    o Discussion:
    - GD: need strong trust since you can't authorize route even if you have
    HoA, CoA and MNP
    You need routing certificates.
    If you don't have that you shouldn't allow it to inject routes
    - Pekka Savola: I agree with GD but in case you really need a
    solution, this doesn't required all of that.
    - There may be a RR test that kind of guarantees that the router (or
    the one that claims to be a router)
    - GD: Unsufficient, because you are changing routing
    - GD: on-path attack is a valid attack and the damage is more severe
    - GD: RR is one thing but might need something very clever indeed
    - Be clear on what threat analysis is: are we concerned of on-path attackers ?
    - JAK: SEND routing certificates can be used.
    - SK: Node on the mobile network send out without Router knowing,
    If there's no SEND, the router could spoofed.
    - MB: Not sure if this is worth it.
    What are we gaining , need to change all correspondents, right ?
    For CNs talking RO to all Hosts in nemo to reduce all signaling to one.
    - CWN: We are not debating the RO solution, the draft is raising awareness
    If you put prefix in BU, then you have this threat
    - SK: Could be a CR on the other side
    - MB: Injecting routing information into routing system, now worried.
    - SK: Applicability statement would apply.
    - VD: Other sol: anycast address, like DHAAD from prefix set aside.
    Agree if prefix length is fixed.
    - CWN: if variable prefix length need as many anycast addresses...

    - TE: Meeeting concluded.


    NEMO WG Status
    NEMO Home Network Models
    TAHI and Connectathon Report
    v4 Traversal for NEMO Basic Support
    Multihoming Issues
    NEMO and Multi6
    NEMO RO Status
    Prefix-Scoped BU and Security Issues