Last Modified: 2004-02-05
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. |
Network Mobility (NEMO) Working Group Minutes Monday, March 1st, 9:00-11:30am at IETF 59, Seoul Korea. Notes taken by TJ Kniveton and Behcet Saryikaya NEMO Working Group chairs: Thierry Ernst, TJ Kniveton Working Group supplemental web page: http://www.mobilenetworks.org/nemo/ ---------------------- NOTES: Please see the Meeting Agenda pdf file in the proceedings or at the group web page: http://www.mobilenetworks.org/nemo/ietf59/slides/ It contains the agenda of the meeting as held. There is also a video of the entire meeting available in the same locations. It was not possible to register with Jabber servers or find a Jabber scribe, so no Jabber log is available. ---------------------- Agenda bashing - WG Chairs no comments Working Group Goals and Milestones -- Thierry Ernst WG goals and milestones have changed. Two more WG documents. ---- Terminology and Requirements Update - Thierry Ernst draft- -terminology-01 New terms: added Nemo-link, Nemo-enabled MR New abbreviation: I-face - ingress interface, E-face - egress interface. Nemo-prefix instead of MNP. Deprecated terms: MONET and TLMR (use MR) LFN / LMN / VMN: have address taken from Nemo-prefix Proposed only MRs may be Nemo-enabled Terms from the usage draft. Home link, home network, MRHA tunnel Virtual home network Are these terms narrow enough? Document ready for last call -- any concerns? NEMO Requirements Updated 2 weeks ago Not much to update -- no discussion on mailing list Design goals may be enhanced? Concern about 1-liner requirements for nemo support Apply to basic support specification -- this might not be the proper place for this? Thierry solicited feedback. If none, the document will move to IESG soon. ---- Basic support draft - TJ Kniveton No comments on the list Open up question to the list about security discussionHow many people have read latest version of basic support draft? about 30-40. Security considerations. Keep this as a separate draft or keep it in the basic support draft? TJ asked input. Any implementations of basic support? There was an interoperability test. Went well. TJ concluded that basic support need security analysis details. ---- Multihoming - Nicolas Discusses multihoming in general not only for nemo. Remove mipv6 specific text and only discuss multi homing in general. New I-D. defines multihoming. Goals, real-life scenarios and benefits. Ubiquitous access. Redundancy and fault recovery. Redirect the flow on another interface. Load sharing and load balancing. Bi-casting. N-cast to multiple interfaces. Preference settings. Nicolas talke about some real-life scenarios. Analysis: split into two. One interface multiple prefizes. Or several interfaces. If one interface no ubiquitous access. Future work. If there is interest. No WG for this work, it could be for new WG, starting with a BOF. Thierry asked if people interested in multihoming from the floor, yes there are people interested. Erik Nordmark - QoS aspects -- sometimes you want the application to choose. Not really being pursued anywhere. Thierry: More opportunity to benefit from Multihoming in NEMO, but some work has to be done in other places Hesham Soliman: Good, comprehensive study from systems view. Probably many v6 on-link multihoming to IPv6, Multi6 can handle other issues. TJ - maybe authors can identify issues, and which WGs can deal with them, then we can discuss Margaret Wasserman - Interesting area, interesting stuff in this draft. Agree w/ Hesham - WGs already working in this space. Should some of this work be taken to those? Does it make sense to form a separate group? Not sure right now, but what do the authors feel is NOT covered at this point, that needs to be done in the IETF? Hesham - host multihoming being discussed in MIPv6, and is important for MRs Margaret: Host-centric multihoming proposal currently being discussed in Multi6, perhaps in the scope. ---- Multihoming problem statement - Chan-wah Ng First talked about the change log. Title changed. Then each section was introduced. Sect. 4 has the problem statement. Moving forward. Decide on which scenarios are useful for Nemo. Any feedback from WG on content of the draft? Erik N. - would be useful to talk about possible ramifications depending on what the administrative boundaries are. There is some text, but we could use more. What if we multihome to multiple home agents in same or different administrative domain? If they are in different domains, they are likely to get different prefixes. CW: that is in the appendix of the draft. Hong-yon Lach: Failure detection is one thing you want to handle. Sometimes, one model might switch to other model (2 MR -> 1 MR). We should make sure that it can handle this kind of shift. Mattias Peterson - Isn't the ide to automatically support multiple of everything? TJ - Hong-yon seemed to be commenting that we need to discover what happens when going from 1 -> n or n -> 1 Margaret: For both of these drafts, what is the difference between generic multihoming issues, and issues directly related to the fact that the network is mobile? We need to look at that harder. The generic issues might not be solved, and we might have to write prob. statements for other working groups to add to this. i.e. what if mobility makes it more advantageous to use some network. What do people think are the real differences in a mobile network? Hesham - that's the point we should emphasize to work out -- if it's NEMO-specific, that would be justification to have in this working group. There might be cases where the problem is not specific to NEMO, but more likely to occur in a mobile environment. Hesham - (1,1,1) - I don't think it's NEMO specific because if you take out MNNs, you still have the same problem you have to solve for the mobile host. Ralph Droms - (N,1,1) - in this slide and the next, how do the MRs have the single prefix that's assigned to the mobile link? How is it coordinated? Ralph - (N,1,N) - the MNNs also have to pick the prefix they want to use. TJ - well this is a mobility-generic problem of address selection. Thierry - Are all the scenarios here useful? Should we consider all 8 scenarios? 4 people raised their hands No? also 4-5 people. Erik - having mult prefix with only 1 MR and 1 HA doesn't seem useful. We could have 2 tunnels over different interfaces from MR, which gives redundancy Even with multiple MRs and single prefix, you need to associate the prefixes with multiple CoAs. Jung - ? University, Korea. (N,1,1) 2 different MRs and 2 MR may have wireless PAN, other may have GPRS. How can these 2 devices talk over this line/ Chan-wah - you have wireless PAN with 2 routers using this protocol on ingress interface Kent Leung - for supporting (1,1,N), I disagree with Erik - there are some cases to support. All of these cases are good to address, and practically we can prioritize or categorize them, and perhaps weed some out. Mattias P - I would like the appendix A1 to be the idea from Eric for the ownership model, and it can help us solve many problems. Thierry - there was a discussion about this last year and it was decided not to deal with this. You list some important factors, we need to address them anyway. Hesham - Having 2 uplinks for MR is irrelevant for 1,1,N scenario. N prefixes does not mean N different uplinks. Margaret - Do you have a specific charter item this document would address? Do you think this merged draft Multihoming Problem Statement should become a WG document to address the charter item? Yes - about 30. No - about 1. ---- Multihoming Threats - Seongho Cho Terminology. Primary MR, alternative MR. Defined failure cases. Link and MR failures. And Black hole attack. Nested tunneling is current fault tolerance mechanism. No solution of MR fails Link failure. Redirection threats. Solution neighbor MRs pre-authenticated. Replay threats. False binding. Fake MR can make a false binding request. Replay threats. Register/unregister neighbor MRs. Kent - This could be a generic issue - having a MR that failed. HSRP or VRRP could allow session to be maintained for mobile networks. Why wouldn't a generic solution deal with this problem? -- There's an assumption that MR has pre-assigned secure association with its home agent. Kent - well regardless of the physical mobile router, you can make it transparent as to which one is doing the registration Erik - have you looked at what people are doing in SEND? Because that might address the first two scenarios where a bogus MR is trying to redirect traffic. This might apply here. ---- Basic support usage - Pascal Thubert Version 01 draft. Mipv6 home is a subnet on a physical link. Virtual home network. Extended home network. Aggregated home network and virtual home network concepts. Kent - cons - no HA redundancy for home network prefix? Mobile home example configuration. Easier management for IT. Root MRs can be defined. And have nested Nemos. Nested route optimization. No pinball routing. Pascal - specific support protocol between 2 HAs could replace this Kent - so a specific type of HA support Pascal - yes same as MIPv6, that HAs know each other, etc. Pascal talked about mailing list questions. Scope is informational. No fix for virtual network configurations. Title. Could be Nemo home network usages. More work needed? This was asked on ML but received no answer. Is there anyone who doesn't still think this should be a WG document? -no comments ---- Prefix delegation - Ralph Droms Two problem delegate prefix from home to MR and local prefixes use for hierarchical Nemo. First problem: HA acts as DHCPv6 delegating router MR as RR. MR acts as relay agent for MNs. All nodes downstream can be configured using DHCPv6. DHCPv6 prefix delegation technology. Hierarchical Nemo. Like local mobility mgmt model standards based (Nemo + DHCP-PD) DHCP-PD based LMM AR-VL AR for visited link owns an aggregation. AR-Vl is Nemo HA for that aggregation. This draft addresses nested Nemo route optimization. Privacy between visitors and visited in nested Nemo. Standards based Nemo + DHCP-PD. How many people have read this draft? - about 15-20 hands Erik - how does routing actually work with this type of hierarchical nemo? You are building 2 separate network - home nw that extends into visited link, and access network that extends into visited link. How do you know how traffic traveling back up goes to which nw. Pascal - MR builds privately its own mobile network Ralph - yes, 2 different prefixes coming from AR Erik - effectively, you're making the MR be multiple virtual routers. You need to re=immplement the same mechanisms in the visited link for VLANs. Must be a virtual router and a virtual DHCP relay. ---- Nested Mobile Network Issues - Hosik Cho MR has Egress and Ingress interfaces. Nested Nemo. Parent MR child MR. Route ad message conflict if MR1 and MR2. Hierarchical MRA solution, put Age field. 3 bits for age. Is this enough? Security problems? ---- RO taxonomy - Hiroyuki Ohnishi Types of RO. MR-to-CN MIPv6 ro over NEMO. VMN-VMN VMN1 HA to VMN 2 HA. Nested Nemo. Packets cross all MRÂ’s Has. RO and LMM. One solution is use DHCP-PD. RO and multihoming. 1,N,* case. AR selection. Not much feedback from ML. Need more comments. ---- Connectathon Report -- TJ Kniveton Connecthaton. Nemo basic support protocol interop tests. KEIO University (Japan), Nautilus Project (Japan) and Nokia (California) implementations were present. Test network comprised 3 HAs, 2MRs. Explicit mode was tested. Implicit was not tested, IPsec MR home registration tested. Tests were successful. This is good for validating the protocol design work being done in this group -- it works. Nemo IPR - TJ Kniveton New RFC 3669 explaining some IPR issues, I suggest everyone should read. Cisco and Nokia have IPR claims. Nokia offered royalty free licensing for open source implementation. TJ reminded group that Cisco has stated they have a no-first-strike policy, meaning that they have never, and do not intend to, ever sue or ask for royalties of IETF related patents, unless it is in defense of someone else suing or asking royalties from them. Same is true for Nokia. Not known if there are any pending patents, but people are welcome to search the issued patents and open applications (which includes Nokia's and Cisco's claims), at the US Patent Office, www.uspto.gov (of course this is only for US patents). See extensive discussion of this topic from prior meetings and in the IETF IPR working group. ---- some Conclusions -- TJ Kniveton Nemo status. Basic support draft will continue its standardisation path. Nemo-external security analysis will be done, starting with Bar BOF at this IETF. Multihoming. What is difference generic multihoming and Nemo specific issues? Can we identify Nemo work? Basic support usages Prefix delegation, maybe split into two delegate from HA to MR and MR becomes virtual router and virtual DHCP server. |