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.nal.motlabs.com/nemo/ -- Additional NEMO Web Page
NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-24

TJ Kniveton <tj@kniveton.com>
Thierry Ernst <ernst@sfc.wide.ad.jp>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <erik.nordmark@sun.com>
Internet Area Advisor:
Erik Nordmark <erik.nordmark@sun.com>
Technical Advisor(s):
Steven Bellovin <smb@research.att.com>
Mailing Lists:
General Discussion: nemo@nal.motlabs.com
To Subscribe: http://www.nal.motlabs.com/mailman/listinfo/nemo
Archive: http://www.nal.motlabs.com/mailman/listinfo/nemo
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-00.txt
  • No Request For Comments

    Current Meeting Report

    IETF56 Network Mobility (NEMO) Working Group Minutes - March 18, 2003
    Scribes: W. Ivancic, Alexandru Petrescu, TJ Kniveton
    Note: the complete jabber log is available at:
    Wednesday, March 18 at 0900-1130
    CHAIR:	Thierry Ernst  
    	TJ Kniveton  
    Reading list: 
      all drafts available on 
    Charter Update and Milestones   - TJ Kniveton 
    NEMO Support Requirements - Thierry Ernst
    Multi-Homing Issues in Bi-Directional Tunneling - Chan Wah, Takeshi 
    AAA discussion
    IPv4 traversal for MIPv6 based Mobile Routers - Pascal Thurbet       
    Basic NEMO Support solutions
    NEMO Support Requirements - Thierry Ernst
      Draft Update
      Basic NEMO Support solutions
    Agenda Bashing - TJ Kniveton
    New agenda item "Basic NEMO support starting point - TJ Kniveton"
    No concerns
    Charter Update and Milestones   - TJ Kniveton
    Charter updated Jan 03. This change was to update some typos.  
    Milestones were also adjusted by a few months to match formation of 
    working group.
    March 03  Terminology document is supposed to be delivered to IESG May 03 
    Submit threat analysis and security requirements. This is not clear yet; we 
    need more activity on the list.
    Aug 03 Submit solution for basic support to IESG - this is the current 
    focus of nemo.
    Route optimization is not currently on the plate, more discussing the 
    issues at this point.
    Basic Support Requirements - Thierry Ernst
    There was a discussion held on whether or not to merge the 
    terminology and requirements draft. Thierry is in favor of combining them. 
    Group members made comments on various points why keeping them separate 
    might be advantageous. Consensus was reached to keep these documents 
    separate. However, we will follow up on the list to validate this.
    Also, we should look at merging the appropriate terminology to seamoby and 
    then simply reference the seamoby document when appropriate.  Part of the 
    goal of the seamoby terminology document was to be a useful document for 
    various mobile protocols thereby reducing size of individual mobility 
    protocol's requirements documents.
    Comments on this topic in Appendix A.1
    Thierry described multi-homing cases -- multi-addressed, 
    multi-interfaced, multi-linked, multi-sited. 
    General comments on multihoming:
    - If mr's need multiple prefixes, we might need a new word for it.
    - maybe we can define the most specific terms like multi-address, so we - 
    need to clarify if m.h. means that interfaces are to be available 
    simultaneously or not.
    - need to clarify if multihoming means you have multiple addresses on the 
    same interface.  If you have multi address, you have several tunnels, each 
    one being a different interfaces.
    - Text should be added that addresses benefits / use of 
    - The degree of layering cannot be enforce, thus it should not be 
    specified.  Rather, the text should simply state the multihoming should be 
    supported. The preferred approach will result from evaluations, not 
    Comments on this topic in Appendix A.2
    General comments.  For many instances the concept of "design goals" would 
    serve nemo better than "requirements".  This pertains to issues such as NAT 
    and PAT transversal, fault tolerance, and location privacy.
    R14 requirement - signaling messages between the HA and the MR MUST be 
    secured.  Consensus is R14.4 requirement for encryption should be 
    removed from basic support.  Will be move to the mailing list.
    Some discussion on location privacy.  Since headers contain 
    addresses, people can always see your home and care-of address, so it's 
    always visible. Somebody in the middle of the network can track your 
    movement, which is a location privacy concern.  No consensus as to 
    whether or not this should be a basic requirement.
    Appears to be consensus to remove R16, impact of protocol on the routing 
    R17: The solution MUST ensure backward compatibility with other 
    standards defined by the IETF. What is the list of protocols that must be 
    backward compatible? We can discuss this on the list.
    For more discussion, see Appendix A.3
    AAA - Chan-Wah
    Issues - Migration transparency, AAA policy transparency, nested MRs and 
    nested AAA relationships.
    Consensus is that we need to understand AAA and what AAA models may be.  
    However, it may be necessary to allow AAA to evolve regarding nemo as 
    traditional AAA models may not apply and it is very unclear as to what the 
    AAA models may be at this time.
    - In the case of mobile networks, we want to have transparency of the 
    For more discussion, see Appendix A.4
    IPv4 traversal - pascal
    Idea described is to be able to traverse IPv6, IPv4 public and IPv4 
    private as well as PATs and NATs.
    Issues - Satellites, GPRS and many other systems use PATs and NATS. 
    Public Access (DSL, etc...).  Also, most of today's 
    infrastructure is IPv4
    Consensus appears to be that having a "goal" of working over various PATs 
    and NATs is fine.  However making this a requirement may not be wise as 
    NATs and PATs are very unpredictable and constantly evolving.
    Multi-Homing Issues in Bi-Dir. Tunneling - Chan Wah and Takeshi Tanaka
    Consensus that pictures in the draft are very useful to discuss 
    multihoming and understand the scenarios.
    Question: If mult-egress links have active open paths, then should the MR 
    actively switch to different route instead of waiting for MNNs to 
    Having multiple address on single interface does not appear to be an issue to 
    be addressed by nemo.
    Having multiple MRs with different home agents requires 
    coordination between HAs.  This is a fancy feature that we shouldn't have to 
    worry about at this time.  The suggestion is that this not be required as 
    part of the basic draft.  However, this could be considered for future 
    It is possible to have two mobile routers can serve the same prefix. we may 
    ask the MR to tell the HA which prefix it's serving. in that case, it may 
    have to tell multiple HAs, or have a single registration, etc.  Some 
    advantages of having multilple HA's with a advertising the same MR prefix is 
    that it can be used for geographically diverse locations of HA and fault 
    For more discussion, see Appendix A.5
    Basic Network Mobility Support - 
    The draft was presented by Thierry Ernst as Ryuji Wakikawa could not be 
    present.  All technical questions should be directed to Ryuji via email or on 
    the mailing list.
    This draft has been tested and implemented under 
    FreeBSD-Release.  They still need to do multiple home agents.
    Some general issues/questions:
    How does this implementation hand more than one prefix for your mobile 
    There appears to be a restriction to using only one prefix.  Thus, how do 
    you create routes at the home agent for both prefixes? instead of having a 
    prefix suboption?
    Question - Does one always have to maintain a binding cache entry on the 
    home agent, even when you're at home?
    There was a comment that deregistration is easy with 
    implementation. However it is unclear as to why this would be.
    For more discussion, see Appendix A.6
    Basic NEMO Support starting point
    Delivery date for Base Document is August 03.
    Requirements will be finalized by end of this month.
    Consensus was reached that the group should use 
    "draft-kniveton-mobrtr" as the starting document and insert material from 
    the other drafts into this document.
    Also, there was suggestion that 
    draft-petrescu-nemo-mrha-02 should updated to included analysis of any new 
    proposals to ease use by group.
    Appendix A - Supporting Discussions
    These were some (somewhat rough) notes on what individual speakers said. 
    Also see the realtime Jabber logs, which provide an alternate log of these 
    discussion items.
    A.0 - Name abbreviations
    TD: Terry Davis
    TJ: T.J. Kniveton
    TE: Thierry Ernst
    PT: Pascal Thubert
    SC: Samita Chakrabarti
    JK: James Kempf
    EN: Erik Nordmark
    KM: Keith Moore
    CW: ChanWah Ng
    VD: Vijay Devarapalli
    HYL: Hong-Yon Lach
    WK: Woojune Kim
    WI: Will Ivancic
    AY: Alper Yegin
    FW: S. Felix Wu
    MT: Michael Thomas
    A.1 - Terminology Document
    PT: we already have these documents.
    TE: doesn't mean it should be changed, just merged together.  Because 
    terminology and requirements should be merged.  They should, could be 
    merged with the seamoby document.  I need more feedback.
    SC: first comment: I like the idea of merging terminology and reqs. I'm not 
    sure, how can you then combine with seamoby terminology.
    TE: I think there are a few words that are already in the seamoby 
    terminology (AR, mobile node, mobile network).  For some reason they use 
    them, so we should make sure we just use them the same way.  They should be 
    combined or alt least, the consistence.
    SC: as long as it makes sense to have them in the same doc, should not 
    TJ: can you clarify?  Seems you want to keep them in same doc?
    SC: yes, I would like them in same doc.
    JK: I think mobility transition, how can you.  If you have specific terms 
    that are mobile network doc, you can keep them.  To the extent that you 
    could reference doc, reduce the size of the terminology doc, reduces the 
    size, attractive
    TJ: suggestions you have how to merge?
    JK: anything in addition for network mobility, keep them in this 
    PT: did you expect someone looking for terms will look them in the reqs 
    PT: terminology is actualy to be found in... terminol. is to be evolved 
    with reqs.  I don't see why we have to merge.
    TE: one single document is easier to track.  There's a relation reqs and 
    terminology.  For instance, multihoming, if you read the reqs doc and you 
    don't have the terminology, you don't understand.  Reqs may look very 
    TJ (no hat): I would think conceptually makes sense to have them 
    separate.  It's because what pascal said.  It might be hard to keep 
    terminology and reqs up-to-date in the same doc.  Specifically if we do RO, 
    where would the terminology be then?  A new terminology for RO?
    TE: for RO we have new documents.  The idea is to submit terminology and 
    reqs as RFC.  New terms for RO will have to be separate docs.
    TJ: ok.
    TE:vote: one doc, who?  two doc who? Conclusion: one doc.
    TJ: please make more comments
    TE: no it's ok
    TJ: we'll have more discussion on this.  It seems like consensus right now is 
    one doc, but we'll have more discussion.
    Appendix A.2
    KM: multi-homing and source address solution doesn't work.  If you want to 
    define a term describing something, I'm not against.  I'm not sure 
    there's a point on this.
    TE: we must be sure we know what it means.
    KM: why that word?
    TE: because it is from definition of multihoming for hosts.
    KM: I object to, I don't think it is useful here, it doesn't apply here to 
    this situation.  If you find that mr needs to deal with many 
    interfaces then you might need it.
    KM: i think it still to be confusing.  For people
    EN: the doc must have to be specific on this.  multi-homing must catch all 
    names for all thise doifferent things.  Draw pictures.  I think in 
    general, if you look at rfc, it treats multhimong.  The term is 
    actually consistent.  Whether it works or not is ok.  You'll be able to 
    talk more accurate.
    CW: define the most specific terms in terms of more specific like, 
    multi-egress interface, so we know which scenario...
    PT: I do agree what CW, we miss some terms.  What if one MR is linked to one 
    HA, we should have more words.
    TE: explicit text.
    EN: finish the discussion and put drawings, figure out. it might be 
    premature to add more terms to this.  You might discover later down
    the rd that you might need more, I'm not sure you need more .
    TE: mh means, read slide.
    VD: the last one, just because a monet has two separate interfaces 
    doesn't make it multhoming.
    TE: what about the case you have multiple address.  Yo can not have both 
    addresses at the same time.
    VD: you mean?
    TE: I mean.
    VD: I mean that is vague, in my oppinion.
    PT: several CoA, several tunnels, each tunnel can be an interface, you're 
    actually multihomed.
    HYL: definition speak loose.  Simultaneously active is different,
    VD: you don't have to uplinks active, one tunnel is up only.  Two 
    tunnels to different HA.  Source selction address.
    PT: I don't want to address that discussion now, the detail is
    Appendix A.3
    KM: basic problem.  This word reqs got attached to this.  Change from 
    title from reqs to "design goals".  It is premature to define reqs at this 
    point.  Strong consensus, it is fundamental.  Others are 
    implications.  Misleading.  Suggest: change the title.  Label the goals as 
    strength and importance.
    TE: change the title of this section
    KM: not, the whole document.  Not everything is requirements in that 
    TJ: solution must fit reqs.
    KM: things will be compromised.  Goals indicate a sense of direction.  
    You'll find compromises.  Casting thins in a rock, find easier 
    TE: ok, other requests.  Location privacy.  I'll clarify what it means.  
    Design goal. I need to clarify that.  There was request to add more text for 
    the benfit of multihoming.  Do you agree we should more text in the 
    TJ: anyone has additional comments regarding km suggestions with respect to 
    change in title?  Location privacy?
    WK: regarding the reqs doc, it can be avoided.  Distinguish what we try to do 
    with respect .  Change
    Fault tolerance: is multihoming.  What is the intent to do?  More 
    specific.  Why we need to have multiple interfaces.
    TE: so you suggest to put more text
    WK: yes..
    PT: location privacy: there are actually 2 things: one for the visitor, one 
    for the visitor network.  OTOH, if the monet proposes a global 
    TE: section 5 of reqs... go on through this.  Question: how many layers of 
    nestedness.  At least two?  More than one?
    MT: how can you prevent arbitrary layers of nesting?
    TJ: by specifying in the draft that it doesn't have to happen.
    MT: when it happens?
    KM: it strikes me, that TCP is there?  There are performance 
    limitations.  What do you try to work well?
    HS: personally I dont think he can make it, if you have proxy RA?  be nice of 
    solutions it just works, it naturally collapses.  I don't think 
    solution should require x levels of nesting.
    TE: what text should be there?
    HS: I don't see a problem with text.  Naturally, protocol becomes. 
    multiple nevels of tunnels, ugly, but slow.
    TJ: question is: if there's a solution that allows max 0 levels of 
    nesting, is it acceptable? 1, acceptable? n, acceptable?
    WI: I think the text, we can not specify the levels of enforcing. 
    Especially because VMN below doesn't see mobility.
    HS: 0 levels of nesting, no.  1 levels.  If pick number, I'd say 2.
    TE: at least 2, fine?
    TE: a first
    KM: The intent is ok.  Performance limitations might be apparent.  It 
    would b
    PT: first point is that we already have cases where the nesting occurs.  
    Later on in the evaluation of proposals.  Scales better then 
    TE: <back on multi-homing>  DO you agree to remove the 3rd 
    requirements and just keep the first line?
    VD: as k said, multi-homing means diffs things.  E.g..   I think we 
    should keep them.
    PT: I don't think we should enter into multiple CoA registration.  This req 
    is not clear whether you have one regi or two regi.  Maybe.., maybe then we
    TJ: I have a question about what exactlly it means in this req.  Says 
    solution must support these things.  Implementation details.  What 
    exactly does "support" mean here?
    TE: maybe word is not fine, maybe "function" is better.
    TJ: i think implemntation details.
    HS: depends on the solution itself.  There is at least 12.1 is much 
    trickier, lots of sub-cases.
    TE: another issue, use case of multi-homing.  Do we need to adapt this req?
    TJ: this says "SHOULD".  You mean?
    TE: I mean. because it was discussed.  I mean 13, not 12.
    TJ: I'm talking about original question.
    TE: ..?..
    EN: so the document says R12.  Under says R13. Slide is not consisted with 
    the numbering.
    TE: yes, there was a mistake.  The req is 12 in the draft and 13
    in. There's a new req which is proposed.
    TD: links of aircraft are not all available.  Commercial ISP.  
    Some of them are voice.  Very different combinations ponts on the 
    ground.  You probably cant maintain a commercial internet session 
    through a low speed digital linl.
    KM: question, this is somehow not stated right.  I suspect that level of 
    fault tolerance is something you want to provide for.  Seems like needs 
    TJ: I would make a comment, I'd like to avoid doing a lot of fault 
    tolerance work for basic solution.  Like link failure should work is 
    implementation.  Not part of basic spec.
    HS: are thes reqs for basic rolusiton?  A document?  Basic support, 
    multiple documents.   I mean , there's a need for this, WG produces.  
    Nothing in reqs draft talks about that.  Basic solution.
    TE: what people think about that?  Different docs for base support?
    CW: wording is strange here.  Fault tolerance, we don't need it in the reqs 
    doc.  It would be a very complicated undertaking, it shouldn't fall on us.  
    Relate to terminology comment, if we do make that change, we have to 
    clearly clarify here wha.
    KM: minor comment: is it useful to distinguish between reqs on support and on 
    implementation.  Clears things up.
    TE: security requirements: payload messages may be encrypted.  Q:Does it 
    make sense?
    EN: a bit of hardplace.  This falls out.  Tunneling can be used IPsec 
    secured, this falls out.
    TE: so you suggest we don't need to add a text for encrypt payload.
    Keith said that some of these things are protocol, others are external of 
    the protocol.  Writing these types of docs is hard.  right level of 
    description is a bit difficult.
    VD: which nemo signalling message needs to be encrypted and why?
    TE: and in which case?
    VD: give me one example?
    TE: I don't know.
    VD: there are none.  Explanation is this.  BU/Back don't need 
    encryption, but authentication.  R14.4 should go.
    MT: one thing you loose, somebody in the middle, location privacy.
    HS: you wouldn't get much privacy.
    MT: 27 levels of obfuscation?
    TJ: I think suggestion is to remove R14.4 and have more discussion.
    MT: reqs document then it should not say that message is encrptyed.
    But that should have.
    TJ: how many more slides.
    TE: one more.
    TE: I need a list of protocols that need to be backward compatible.  
    Maybe on the list, we can discuss.
    MT: R16, how do you test for that?
    TE: this is form the list discussions.  We have a clear idea of the basic 
    MT: I would remove R16.
    TE: a few issues.  Read slide.  Question, do we need to have reqs from this 
    organizations.  It is too early maybe.  Reqs with specific use case.
    PT: Signaling: it's not really we can place as req, but use as an 
    evaluation criterion.
    TE: minimize: keep vague.  Between two solutions choose one.
    PT: point out which criterion.
    TE: tricky to do it.
    PT: you can't precise and
    WI: I don't think you should have a separate req for different 
    applications.  You should take into consideration what their needs are.  I 
    strongly beleive you should have cross-boundaries between 
    administrative domains.
    TE: what do you think about preventing a mr in different domains?
    VD: makes more sense to have it in the req document.
    TE: last two req is the other speakers.
    MT: redundant with the multihoming req?  How access control is done is 
    related to.
    TE: kind of falling on that.
    Appendix A.4
    MT: does this WG actually needs to consider this?
    TE: question is where we should discuss that.
    CW: a possible approach is to id problems.  Problem statement draft reqs to 
    other WGs.
    EN: go back one slide.  Number 1 there I think there is another way of 
    describing that at a hoghe lrevel of abstraction.  Would monets might end up 
    doing nesting AAA relationships.  There are sort of boundaries AAA 
    domains.  Nesting.  You want this nesting transparent as much as 
    possible.  Number 2. Reflect nesting.  It's another way of thinking of 
    this. Figure out what is the reasonable model fo thinking about AAA 
    issues.  People can actually understand how we plan to fit this up in the 
    AAA.  Samepicture.
    TJ: based on that idea, layering of AAA associations, do you think there are 
    reqs that should be communicatied to AAA, or it is just a matter of 
    EN: number 1 yes, number 2.  Req or not, business issue.
    TD: migration transparency.  You should realize we handoff between 
    different cells, you don't necessarily the same bandwidth.
    Aircraft. Something you wanna think about.
    MT: skeptical about being there _a_ AAA model.  There is a downside of 
    concocting one at this point.  My preference would be to allow this to 
    evolve more.  It may not even have much to do with traditional AAA 
    altogether.  Single model might be premature at this point.
    AY: id between mobile ip mobile nodes and monets.  Coupled.  Tightly 
    coupled in a signel transaction.  In the monet case there is 
    transparency.  Billing aspects might be different.
    PT: IPv4 traversal slides.  read slides.  I'm asking for a 
    requirement here.  The requirement of v4 traversal.
    TJ: question is: what is the business of this WG for dealing with this 
    issue? Do we need to have an additional req?  Do we need to just say we 
    support this?
    KM: nats are not predictable.  they don't ensure intergrity of payload.  if 
    you're trying, you're constraining .  NATs are not stable, keep 
    PT: ALG?(Application Level Gateways)
    KM: no, about advanced NAT.  basically you make your lives very very 
    PT: maybe you would place boundaries of which types of NATs.
    KM: defining nat acceptable behaviour is a rathole.  Putting it as a 
    requirement is difficult.
    PT: how would you formulate the req to put this.
    KM: i think it is too specific.  This derives from operational need.
    PT: gprs is deployed.
    KM: rathole.  It is not going to support mobile ip and mobile 
    networks.  PT-KM argument.
    People lining up.
    TD: for whatever reason aircraft industry chose to assign private 
    addresses to cabin.
    TJ: using a NAT?
    TD: sort of assume nat.
    CW: sort of agree with K.  I'm not comfortable with making it a req.  
    Because if we design that into the base, we've been grabbed down by 
    history when we need clean.  Not as a req.  As an informational.  people can 
    work with GPRS.  Go for it.  Basic solution should not have this req.
    MT: seems WG group.  NAT free world. later decide what to do about 
    reality.  Has the advantage of allowing progress.  horrible ratholes to 
    happen.  reasonable protocol might actually happen, rfc number before next 
    KM: You impose a burden on the group.  Goal and not req.
    TJ: couple of different viewpoints.  Please vote on: req for working on 
    this, design the spec for a nat free world and leave req later, 
    3-design for a nat free workd and come Comment?
    EN: consider is also there mgith be a reasonale path forward.  
    Composing things.  v6ops.  Basic Mobile IPv6 solution.  Headers get 
    bigger, but might be less complex.  Not many cycles on.  Simplifying 
    assumptions.  Compose existing stuff together.
    PT: I did not actually give here.  We've being doing some work. Mobile IPv6 
    can be used as a vector to pass nat or path.  Actually the midflows fits 
    very well the picture, store the states.  ALG things. PAT/NAT.  It's easy 
    but limited to mip, why.
    TD: go with the "goal" rather than "requirement" for NAT traversal. Will 
    make it easier for the spec to move forward.  Common techniques for 
    traversing nats.
    TJ: we can't prevent people to be interested in using nemo protocol to 
    traverse nats. Please vote on adding a req? People raise hands.  In favor of 
    not adding a req?  Consensus: not having a req for that.
    Appendix A.5
    HS: question, bullet, undesidered.  why?
    CW: because it takes time for mnodes to actually discover home.
    HS: why is it ok for ipv6 but undesired for nemo?
    CW: for nemo it is multiple egress links.  mr should actively, instead of 
    waiting for mn's to discover.
    HS: I don't disgaree there it would be nice to have something faster. It 
    might be a genereic problem.
    CW: it is a generic problem, but.
    HS: I'm not sure I have
    EN: the first bullet lead to believe IGP leads to imply to recover. It 
    would be interesting to notice that ...  My model is assuming one 
    organization runs a ha and runs mr and assign one prefix to monet, run IGP 
    between the mr and ha. what are issues that are mobility, wireless 
    flakiness, will pop up?  What do we need to do different?  Pictures are 
    very useful, good for group to do.
    WI: one thing to consider: multihimoing on wireless links, fast 
    handovers, think about radio techs, thin.  Change two things is a 
    problem. Kep radio in mind when developping seolutions.
    AY: what is the purpose of different HAs sending different prefixes?
    This is not basic requirements.
    TE: you mean no reqs, but wg item we can think of.
    AY: fancy features
    TE: too early.
    AY: at least too early.
    WI: not in the basic draft..  Geopgraphically different locations for your HA
    HA: have different HA for the same mobile router at the same time.
    CW: diff mr, multiple mr, each time, distinctions..
    TJ: comment, under mip, when mn walks away from home.  It will be served by 
    any ha on the mobile link.  ha can advertise, multiple prefixes served by 
    other HAs on the link, but the binding for a prefix will be served by 
    whatever HA is serving it.
    HS: multiple has with same prefix is no problem.  I thought that would 
    work, do we need anything else?  Am I missing something?  Unless there are 
    two home addresses.
    TJ: yes, it should work.
    FW: requirements on fault tolerance.  Should be considered seriously.  
    Multiple HA.
    TJ: do you think there should be any functionality?
    FW: right, currently Mobile IP base solution is very close to what .
    TJ: you suggest any specific functionality in the nemo spec that is not in 
    Mobile IPv6.
    FW: define coordination between different HA for supporting the same 
    HS: which problem are you trying to solve.
    FW: both cases.
    HS: two ha defending same home address.
    FW: should not exclude the possibility.
    AY: requires coordination between HAs.  Why?
    AY: different mobile networks.  They are disjoint, traffic just follows 
    prefix.  I don't see any integration that would require 
    coordination between has.
    CW: what if the mn chooses the other ha.
    AY: the mobile node will first choose a prefix and then configure an IPv6 
    CW: must choose a default router.
    AY: is not necessarily on the same.  theres no mn . i don't see .  just 
    picks a prefix.
    PT: prefix sees and, same prefix. basically with nemo we don't have a 
    clear req.  Same prefix several times on ...  redundancy used it better.
    Appendix A.6
    VD: what if the mobile network has more than one prefix?  How do you 
    create routes in the HA for both prefixes?
    TE: you send a different BU, you send one BU but with different.
    VD: but you said you're not going
    TE: I don't know in this case.
    PT: if the mobile prefix is actually behind .  Why you want , I don't 
    think it is necessary.
    TE: ok.
    TE: Changes to mobile ipv6. read slides.
    MT: not clear to me that HA ipsec draft works directly.  I'm not sure that is 
    a given.
    TE: say that again.
    MT: it ....
    TE: there are changes of course.  Not exactly the same.
    VD: basically Ryuji does provide an example.  You're missing something you 
    have to always maintain a binding cache, even when you're at home.  Since 
    there is no home.  What you meant by "de-registration"?
    TE: I can not really give you the motivation.
    VD: something is wrong in the drraft.
    TJ: return home link, not home network.
    VD: you have.
    PT: scalability problem not addressed in the draft: there is no home 
    network in the network, you'll have to do coordination, routing 
    protocols.  Reminds me of what we talked about before about 
    multi-homing.  Same kind.
    TE: no more needed.  Show that there is different ways to solve the basic 
    support issue.  It needs to be considered. Questions?  Please ask 
    questions on the ml, ryuji will answer.
    Appendix A.7
    JK: recommend right away, don't get caught with requirements.  Minor 
    things, go for it.
    VD: no need of threat analysis document.
    TJ: security review.  Sanity check on that.  Any opinions on starting 
    point for text?
    PT: I'm missing the step here.  Should figure out what are the problems 
    that are left to be solved.  NEMO seems to have a basic kernel, mn on the 
    egress interface and the mobile ip router, no RO, that's kind of .  We want 
    to add a few things.  Which exactly are those.  Try to say take 
    everything from the draft and then we amend it.
    TJ: what we have right now.  There's work to id exactly.  That's 
    probably part of the process.  The discussion on the mailing list.  It is 
    not really possible to do that ahead of time before .  Are there 
    additional issues before we can start making a solution?  Or using one of 
    the existing solutions?
    MT: which draft has the fewest tweaks from Mobile IPv6 basic solution.
    TJ: my answer is b (MRTP).
    MT: what is the distance between these drafts?
    TJ: answer, my personal impression, there isn't too much 
    controversial.  Creative ways to do, exist.  Interesting points. There are 
    limitations, obviously.  I would say, my personal, not too much 
    controversies.  I think it is possible to proceed now.
    MT: a real bare bones initial standard and then as things become more 
    apparent, add optimization.
    TJ: Yes, and the RO is split off as a separate task.
    SC: suggestion, I was wondering if you one of you could put together a list 
    that contains the common things.  Basic solution, and then can have some 
    analysis on different aspects of the draft.  It would be easy for the WG to 
    decide which one to pick.
    TJ: the analysis is in Petrescu's document.  Basically looking at the 
    different reverse-tunneling solutions.  Any suggestion beyond that?
    SC: include Ryuji's draft and more email discussion in that draft.
    TJ: ok.
    PT: bare bone approach. PSBU thing.  What is the exactly the bare bone?  Do 
    we have a clear requirement of having to update dynamically the HA?  Can we 
    have a basic basic?
    TJ: there is no specific req.  You really have the choice to do either one.  
    The way that the solution will address the agreement.
    PT: not have to do it?
    TJ: it is implicit that HA must know what the prefix, otherwise it could not 
    run packets.  AM i missing the point
    PT: I have in mind that the stated definition will be there anyway. 
    Exchange that, seems to me that it is , not needed in the bare bone 
    approach.  It will come, but later.  Which of those that will come. 
    Example, Ryuji draft is all about this.
    TJ: ok, I have a question.  Does the WG feel comofrtable to choose a text 
    starting with now?  Raise hands, 2 to 1.
    MT: what would be the possibliity.  If there are subtle 
    differences, that will probably good exercise.
    TJ: authors of these drafts collaborate and choose some texts.  Bring 
    controversial topics to the list.
    PT: I prefer the initial draft: take your draft (MRTP) and take the best of 
    the other ones.  Your draft has two sides: simple and complex.  Keep the 
    TJ: draft explanation: has two cases.
    HYL: team should be formed, not all authors.  Some other people who are 
    interested should be able to participate.
    TJ: other people who are interested that other authors should get 
    TJ: OK, from these suggestions, how about this? We start with MRTP as the 
    text, and have the draft authors collaborate on editing.
    Vote: unanimous in favor (about half the room or so).


    Nemo Requirements
    Nemo Terminology
    NEMO Working Group Charter and Milestones
    AAA and NEMO discussion
    NEMO Base Draft: Status and the Future
    Basic Network Mobility Support
    IPv4 traversal for Nemo
    NEMO Multi-homing Issues