NEMO (NEtwork MObility) WG Minutes IETF 55th - Atlanta, November 2002 Chair TJ. Kniveton, Thierry Ernst Slides on the IETF web site the NEMO additional web site: http://www.nal.motlabs.com/nemo/ # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Agenda Bashing: Chairs # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Removed Threat Analysis, did not receive enough input; Added investigation of route optimization (RO) problem scope Questions: ~~~~~~~~~~ James Kempf (JK): OSPF and other routing protocols can be useful for NEMO. We should have routing specialists in the group for conversations on routing optimization. # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # NEMO WG Charter Review: Thierry Ernst (TE): (See slides) # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mobility of entire network; mobile network is connected to the Internet via MR; mobile network is a leaf network (no transit network allowed); multiple MR should be assumed. Nodes behind MR are standard IPv6 nodes Stepwise approach for the solutions: 1. First step is "basic support": Objective = maintain support to all nodes behind MR; no routing optimization at this point. Solution = bidirectional tunnel 2. Next step is optimization of basic support: "extended support". Requires much more intensive investigation. Based on findings, determine if we should standardize a solution. If yes, recharter. Methodology: Before solutions look at problems. - First, informational document to describe terminology and requirements, - Second, threat analysis and study of issues for basic - Then, specification of basic solution - Next, investigate and compare different ways for improving routing. WG will: - ensure adequate security - monitor other related WGs and make sure existing protocols work fine - NOT going to worry about interior of NEMO's routing topology Questions: ~~~~~~~~~~ Pascal Thubert (PT): Guess it is hard to get a single document for the RO solution. TE: Depends on results of investigation. Justin Dean (JD): Last slide, either mobile IP of routing protocol. Mobile IP approach is more emphasized than routing protocols. Routing protocols in one place only. Is this intentional rather than looking at MANET [NOTE from minutes editor: paraphrase, please check]. TJ: It was discussed on mailing list. The easiest solution is to use mobile IP. It is currently understood that Mobile IP is a starting point for a basic solution. Basic support assumes mobile IP for support to upstream only requires one IP address for connectivity. Extended support to optimize routing is conceivable in a more direct way. JD: Do you allow Mobile IP networks inside Mobile IP networks? TE: Yes. this is what we call nested NEMO JD: Just a concern if too much done Mike Ramalho Cisco: One path to mobile router or multiple wireless links allowed ? How do you choose between them ? Running routing protocols to decide this. TJ: Covered in presentation, Multihoming on the plate. # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Terminology: Thierry Ernst (TE) (See slides) # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ New terms: - MIPv6-enabled node: a node which can perform MIPv6 function - NEMO-enabled node: has NEMO capability, has been extended for some kind of NEMO support E.g: Basic Support: HA's and MR's are the only NEMO enabled nodes. New terms about nested mobility: - Root NEMO: NEMO connected to world aggregation. - Parent NEMO: - Child NEMO Child and Parent NEMOs are immediately adjacent, Parents are closer to the Internet. Leaf NEMO: unlikely to be used. Multihomed NEMO: - clarification about Mutlihoming + Nesting Questions: ~~~~~~~~~~ Erik Nordmark (EN): Maybe we should be using a different term than Home Agent when we deal about multihoming. If a part of the fixed/parent topology fails, has a redundant path. TJ: Is there a term for that in MIP? EN: Not in MIP, looking at different addresses for a host. It's different here, looking at routers, no single point of failure in the path. TJ: 3 different cases: 1. multi-access: 2 MRs 2. multi-homing: single MR of different media types. 3. more than one HA (with or without multi-access) TE: Currently individual draft. Do we all agree? Seamoby folks have requested parts to be merged with the terminology document in the Seamoby WG. Maybe some parts should be incorporated in a common doc, but not all. Charles Perkins (CP): Reasonable to merge terms with the terminology document in the Seamoby WG, as long as we don't lose control on them. Maybe not owned by Seamoby. Shouldn't have different terms for same concepts in Seamoby and MANET. # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Requirements for Basic Support: TJ Kniveton (TJ) (See slides) # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ BOF sessions, list, number of people have written up requirements going through drafts, extract common elements, what the differences are, controversial things. non-controversial in single docs. Develop common document of requirements for basic support. Get better understanding of basic support, how is it going to work. 3 initial documents still active (TJ, TE, Christophe Janneteau), AAA requirements, Architectural Reqs. Reviewed in past BOFs, minor changes on mailing list discussion. Most of the items are agreed upon. Common list of items, agreed upon, not shot down, not doubly speced (see slides): #1 continuous internet connection while MR moving. #2 basic support mobile IP and reverse tunnel #3 transparency, nodes in NEMO can be unaware of movement. Simple IPv6 node continues to work. #4 CN's do not need to be aware of MIPv6 MNN being in NEMO. #5 Fixed Nodes and Mobile IP mobile nodes. #6 MIPv6 MNs can use link as home or visited link #7 Multihoming works : incorporate EN's ideas on distinctions between these. #8 Co-operate with other groups doing AAA&etc. #9 Scalability: support large number of mobile networks, #10 Support roaming in different domains of control: one reason for mobile IP (since supports). #11 NEMO is a stub network, not asked to carry traffic for nodes which aren't part of the mobile Net. #12 MNN's Above IP layer shouldn't be affected by the mobility. Questions: ~~~~~~~~~~ Ralph Drams: Clarify what you mean by Internet connectivity ? Same address used, Src/Dest address which varies over time or stable addresses? TJ: IP address on Mobile network prefix is continuously working regardless of MR's movements 2 types of mobility : Home Address mobility, always contactable. Some address to get and send packets. Goal in MIP to get both of these. Nodes in NEMO has a permanent address based on NEMO prefix. Nodes visiting can get CoA in that network. Ralph Drums: It might be good to clarify #1. EN: Maybe this is a clarification of address stability. Address doesn't change while mobile network change its point of attachment. CP: part of #3. Subnet structure in mobile network, The communication between nodes inside NEMO goes on whether there's internet connectivity or not TJ: Follows from principle that things in NEMO unaffected by mobility. TJ: Depends a little on Routing protocols CP: Please don't add further restrictions. Thomas Narten (TN): #1 ambiguous. #1 looks more like a goal rather than req. Sounds stange/oxymoron, some effect from motion (while handing over..). It should say that when MR moves and is attached to the network, it provides same level of network connectivity to LFNs. Samita Chakrabarti, about #4:Maybe clarify why CN can see motion of MN relative to NEMO. TJ: 2 layers of mobility. MN moving in NEMO looks like host moving in a fixed network. When the NEMO is moving, it is not desirable for fixed nodes to notice movement. RO for MIPv6 CN's can be done to MR's HA (goes through NEMO tunnel). TE: nothing peculiar to NEMO, get prefix of NEMO, since unaware of of NEMO movement, just sees NEMO prefix. PT: Nested NEMO is a complex case. Communication may be broken if the uplink dies. LFRs still should be able to communicate. PT: 2nd point. visualize MR and NEMO HA : CoA and HoA test of NEMO are located in same box, not co-located. Routability optimization for MIPv6 CN. TJ: Hard to describe without pictures... MN can update CN with CoA. CoA is in MR's HA network, packets will be send to the MR's HA, but may not have to go through MN's HA. Michael Thomas (MT): #9. Authentication in binding addresses to prefixes, MIP can punt on this since MIP may take FCFS stance, without auth credentials. This WG has to deal with it. TJ: In basic case, we are not solving this problem. That is why reverse tunneling is used. EN: Address allocation and authentication are different, use existing auth protocols. TJ: MIP assumes that routing fabric is trusted. packet gets to aggregated located, trusted to be read at that address. MT: MR not trusted by routing fabric. Bind Auth creds to prefix. TJ: on ML needs to have 'binding' between MR (SA authed) and ability to use prefix. MT: If they don't deal with problem in MIP, you'll have to deal with. EN: Containment. About CP's comment. If you disconnect ethernet, packet forwarding on downstream interfaces should still work (between MNNs). So, in NEMO this shouldn't add any dependencies which are already there. TJ: Interface connected to NEMO shouldn't be affected by MR's upstream interface state. Rajeev Koodli (RK): if NEMO disconnected how do we do HoT ? More difficult to do HoT in NEMO. EN: Not different to disconnecting ethernet. TJ: prefix used for NEMO: where the aggregation for that prefix should be. Need to be able to do DAD &etc. All nodes on the NEMO, not disconnected. Kenchi Loa, Motorola: item #9 need to deal with more problems than MIP: using routing proxy. When MN moves away, HA can't do link local defense &etc. NEMO group has to be more active in dealing with issues. TJ: related to what I just said: Imagine prefix on link of MR, uplink prefix goes to HA, when at home. The entire prefix moves with NEMO. Just uses tunnel. all the routing on the local link will be on the MR. Behcet Aarikaya, Alcatel: Procedural, looks like re-inventing wheel chairs. Have that document. All of these have been stated in document. May clear up this controversy. Justin Dean: #10, ambiguous what large number of mobile networks? Don't want very large number Christian Huiteman: number is 10^12 JD: what is the limit on # of nesting TJ: I'm going to address in presentation. GT: Are there any differences between maximum tunnels/nests from IPv6 compared to NEMO? TJ: Based on MTU and overhead # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # NEMO AAA Reqs. Ng Chan Wah (CW). (See slides) # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MT: Seems to be premature to start talking AAA requirements. When basic requirements are well understood before requirements of offloading policy. CW: We looked at problem, so when basic support ready for AAA, some base work has been done. Premature but good since some Alper Yegin (AY): look like generic AAA requirements. Uses NEMO terms, but generally applicable TJ: Need to get done later, good to consider some requirements. Agree with AY that generic AAA requirements. Issue 7 interesting case, looks like MR should do local attendant function to do access control, AAAL usually in same administrative domain, MR/AAAL moving may not be in same domain. AAAL any special issues. MT: Not even sure if it should support AAA, completely orthogonal as on normal router, NEMO shouldn't be unfriendly AY: #7. AAA only for roaming nodes. EN: If I want to provide space for visiting MNs then I should be able to use or not AAA. In general, we separate what's happening inside NEMO vs. outside # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Issues for Basic Support: Hong-Yon Lach (HYL) (See slides). # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relation between HA and BR on the home link ?; contents of the BU ?; HA needs a way to acquire routes towards the mobile network link; ... See slides. Questions: ~~~~~~~~~~ EN: When BR & MR exchange info to optimize, are they in the same domain? HYL: Yes, but HA not involved in IGP. # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Route Optimization Problem Space: Pascal Thubert (PT) (See slides) # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MT: Are people actually thinking of using RR to protect prefix ? PT: Not in this case. MT: RR is fragile for MIP and won't work for prefixes. This work could end up in a rathole. This entire concept of reusing this scares me. May not be an issue for one node, may affect a /8 RR has known limitations PT: You're looking at solution, may not be used. Maybe for CR. MT: Make sure any auth problem doesn't occur. Fruitless. TJ: No suggestion that RR should be used. EN: Not sure about how grounded [CR - VMN optimization that Pascal presented]. Not sure why a CR needs to be involved. CR involvement can't be understood aside CR and MR are in same ad domain. Having Internet makes confusion. PT: Pretty high level. EN: maybe scaling issues, and security issues in distributing trust. RK: what is the benefit of doing this between VMN and CR? Are we going to do this for all CN's behind CR? PT: That is the first question. 2nd how does the CN get the traffic. RK: I still don't understand the benefit. PT: CR may be aggregating for all prefixes... set of routes to all prefixes. MT: Said before, say it again. basic wrapped around security axle here. Maybe not folded into some basic NEMO specification, make separate function. TJ: RO not going to be in basic specification, and it is not needed to create a RO solution. WG to be rechartered a bit if that is the case. Why RO is critical for large deployment ? PT: Waste of bandwidth. Large deployment packets bouncing lots of times, doesn't give ISP any more money to have packets sent many times. TJ: Io nesting, only one level of nesting, scales linearly to how MIP works. Terry Davis, Connexion - Satellite ground station. Our HAs are 5,000 miles apart, so RO is important to us. EN: This work is supposed to be investigated by the group, but not solved unless a charter revision is done. WG chartered to do Basic, and not to produce RO solution, don't get distracted by interesting RO. Look at routing and what is mobility and how they fit together. # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Future Steps and Milestones: TJ (See slides) # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Delayed in finalizing and approval. Revising dates. First deliverable. things that need to be done; Threat analysis needs to be done with internal/external to WG people. Analysis for RO final deliverable. Feasibility for prefixes, being ready to take on. Q's & comments.?? Acknowledgments: The present minutes are have been compiled based on the notes provided by Greg Daley, Pascal Thubert, JinHyeock Choi, Ryuji Wakikawa and the NEMO Chairs.