Last Modified: 2003-02-24
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.
|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.|
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: http://www.jabber.com/chatbot/logs/confe rence.ietf.jabber.com/nemo/ Wednesday, March 18 at 0900-1130 ================================= CHAIR: Thierry Ernst TJ Kniveton Reading list: all drafts available on http://www.nal.motlabs.com/nemo draft-ernst-nemo-terminology-01.txt draft-ietf-nemo-requirements-00.txt draft-ng-nemo-multihoming-issues-00.txt draft-wakikawa-nemo-basic-00.txt draft-petrescu-nemo-mrha-02.txt draft-thubert-nemo-ipv4-traversal-00.txt AGENDA: Charter Update and Milestones - TJ Kniveton NEMO Support Requirements - Thierry Ernst Multi-Homing Issues in Bi-Directional Tunneling - Chan Wah, Takeshi Tanaka AAA discussion IPv4 traversal for MIPv6 based Mobile Routers - Pascal Thurbet Basic NEMO Support solutions NEMO Support Requirements - Thierry Ernst Draft Update draft-ietf-nemo-requirements-00.txt draft-ng-nemo-multihoming-issues-00.txt Basic NEMO Support solutions draft-wakikawa-nemo-basic-00.txt ======================================== ============================== 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 multihoming? - 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 requirements. 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 fabric. 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 network. 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 discover? 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 development. 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 tolerance. For more discussion, see Appendix A.5 ======================================== ========================== Basic Network Mobility Support - draft-wakikawa-nemo-basic-00.txt ======================================== ========================== 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 network? 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 confuse. 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 document. PT: did you expect someone looking for terms will look them in the reqs doc? TE: 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 lighter. 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. TE: 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 document. 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 solution. 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 section. 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 prefix... 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 preferred. 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 reworking. 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 solution. 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 understanding. 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 evolving. PT: ALG?(Application Level Gateways) KM: no, about advanced NAT. basically you make your lives very very difficult. 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 millenium. 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 prefix. 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 address. 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 simple. 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 involved? 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).