Last Modified: 2003-10-20
draft-ietf-mobileip-ipv6-24 (RFC XXX) and draft-ietf-mobileip-mipv6-ha-ipsec-06 (RFC XXX)
The protocol as specified in the above two documents can be considered as the baseline or minimum protocol set for implementing IPv6 mobility. During the development phase of the base protocol, a few additional features were identified as necessary to facilitate deployment (described below).
The primary goal of the MIP6 working group will be to enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments. Additionally the working group will ensure that any issues identified by the interop testing of the MIPv6 specifications are addressed quickly. Specific work items with this goal in mind are listed below:
1) Create and maintain an issue list that is generated on the basis of interop testing and address these issues as enhancements to the base protocol
2) Features such as renumbering of the home link, home agent discovery, Route Optimization, which are currently a part of the base specification can be specified more explicitly as separate specifications. This will also enable modularizing the Mobile IPv6 specification further into the minimal subset and add-on features. Some of these specifications will be identified as base mechanisms of Mobile IPv6.
3) A number of enhancements to basic IPv6 mobility were identified during the development of the base specification. These enhancements will be taken up in a phased manner depending on the priority identified with each. Below are listed the work items to be taken up by the WG:
- A bootstrap mechanism for setting up security associations between the Mobile Node (MN) and Home Agent (HA) that would enable easier deployment of Mobile IPv6. This bootstrap mechanism is intended to be used when the device is turned on the very first time and activates MIPv6. The WG should investigate and define the scope before solving the problem.
- Improving home agent reliability: in the event of a home agent crashing, this would allow another home agent to continue providing service to a given mobile node.
- Support for a Mobile Node changing its home address, either because of renumbering in its home network or because it periodically changes addresses (perhaps via RFC3041)
- Route optimization will require security mechanisms for trusting and updating the binding information.Return-routability is the basic mechanism for route-optimization. Mechanisms using a shared secret Key/Security Association will be considered. Methods for establishing a security association between the mobile node and the correspondent node are out of the scope of the WG.
- The working group will also document problem statements associated with deploying Mobile IPv6 in the following areas: a. Mobile IPv6 issues in the presence of firewalls b. Mobile IPv6 deployment and transition issues in the presence of IPv4/IPv6 networks c. Multicast issues
It should be noted that there are potential optimizations that might make mobile IP more attractive for use by certain applications (e.g., making handovers "faster"). The latter category of optimizations is explicitly out-of-scope at this time; this WG will focus on issues for which there is strong consensus that the work is needed to get basic mobility deployable on a large scale.
|Nov 03||Problem statement documents (to IESG): (1)- Issues with firewall; (2) - Mobile IPv6 transition between v4/v6 networks|
|Jan 04||Bootstrapping problem statement to IESG|
|Feb 04||Submit MIPv6 MIB to IESG|
|Mar 04||Alternate Route Optimization scheme to IESG|
|May 04||Home agent reliability to IESG|
|Aug 04||Bootstrapping solution to IESG|
|Nov 04||Separate specs for Home Agent (HA) Discovery, Route Optimization, Renumbering to IESG|
MIP6 WG Monday November 10th, 2003 Chairs: Basavaraj Patil, Gopal Dommety http://www.mindsrping.com/~bpatil/IETF58/MIP6 Agenda Bashing (Basavaraj Patil) Document status (Basavaraj Patil) MIPv6 docs to be moved to the MIP6 WG from the Mobile IP WG (which is closing) IANA assignments for the base spec ongoing MIPv6 remote interop testing (Samita Chakrabarti) Connectathon 2004 was announced mobileip-ipv6, mipv6-ha-ipsec, perhaps nemo basic support draft will be tested Connectathon update - new co-ordinator (UNH - Hiroshi T) Design team was formed to develop guidelines for uniform remote testing over IPv6 Internet. This effort is similar to 6-bone testing. This effort does not replace regular MIPv6 interop events First draft is an individual submission. Need to get WG consensus if this should be a WG doc, on the interest and the Informational nature of the draft. The purpose of remote interop testing is for some implementers to dedicate stable MIPv6 systems in the Internet, other implementers can check basic functionality. Requirements to participate: all nodes must register through ETSI web page, dedicated HAs, MNs & CNs in the test network Central registration at: list.etsi.org/plugtests-mip6.html Comment from someone (could not catch the name) about helping out with reviewing the test plan. Continuing... (TJ Kniveton) Discussed issues of IPv6 address allocation, security association, virtual home link, diagram of nodes, solicited more implementer's comments are welcome Current thought is to support Security associations - three methods to auth MN: NONE, AH, ESP Inter-home agents protocol (HAHA) (Ryuji Wakikawa) Discussed the Problem statement: need for reliability, load balancing (HA can be serving large number of MNs, if MN not uses RO HA becomes bottleneck of communication; several HAs sharing the load for the same home network), redundancy (with HAs on topologically different links), MN cannot currently register its binding to multiple HAs simultaneously, serviceability, HA switching. Discussions on mailing list: applying existing protocols (VRRP/HSRP, BGP model, CARP-like mechanisms) Goals are redundancy, load sharing, flexible HA selection James Kempf: Want to do ipsec between HAs? (Yes) If you use ICMP you can't because the spec prevents you from doing it. TJ Kniveton: MN can change to be registered with best HA, how do you figure out which is best? Ryuji: MN knows some of the HAs... TJ Kniveton: Needs some more thinking... MN home address will be moved to new HA. What if HA advertises address that is not topologically correct... Q: If you route packets back to primary HA, how do you then reduce load on HA? This actually increases load on HA. Also, if two HA advertise the same prefix MN will only choose one. How will second prefix enter routing table? Discussion about this ending with "Don't think you get my question..." Q: Big aggregated prefix will be split into several... to reduce load you don't route traffic back... Basavaraj Patil: Need to discuss what the problem is that the WG wants to work on. Need problem statement & problem definition. Then decide this is problem really relevant that we should work on. This is one solution, there are probably more. We need to look at that. Alpesh Patel: Routing with multiple anycast addresses popping up...? Any analysis on this? Ryuji: Will make problem statement & send to the list. MIPv6 advanced socket API extensions (Samita Chakrabarti) API is useful for debugging, tracing, policy applications etc. This is a combined effort of IPv6 & MIP6 WG Updates & resolved issues, suggested changes. Next steps : Basavaraj Patil: Discussions with IPv6 WG, happy to let work be done here, in conjunction with IPv6 WG, ok to make this a WG document if there is WG consensus. Problem statement for multi-homed mobile nodes (Nicolas Montavont) List of current work on multi-homing What's missing: terminology, motivation, accurate & common goal Some issues are related to Mobile IP while some are not A MN is multi-homed when it has several addresses to choose between Benefits of multi-homing: redundancy, ubiquitous computing, load balancing, preference settings Why MIPv6? Open issues Which WG to take this to? James Kempf: This is what I want to talk about at bar BoF tonight. Have invited people from transport area to come. Q: Some issues related to MIPv6, some not, those related to MIPv6 are obviously for this WG. Basavaraj Patil: Aspects for MIPv6 are interesting. Making bigger changes to current MIPv6. How important is it to get this done right now? Need to also look at if problem can be solved in different way. Suggestion to look at problem statement & scenarios. Thierry Ernst: Good to investigate problem statement, but where do we do it? This WG? Nemo WG? How to coordinate activities between WGs. Q: Node with multiple interfaces... that's the problem. Raj: ADs have any comments? Thomas Narten: No clear answer. Clarify problem statement, and ask question about which WG for each specific problem. Maybe there is no WG, maybe we need BoF. Basavaraj Patil: This is problem also seen in nemo. Don't start new WG and work on generic solution. Have to consider fact that MIPv6-specific issues belong in this WG. Q: Some issues are very specific; which interface node picks is totally internal to node. How multiple pieces are put together? Applicable to MIPv6: you cannot have MN with multiple addresses work with MIPv6 today. Basavaraj Patil: Let's continue discussion, look at scenarios, see what comes out of bar BoF. MIPv6 MIB (Glen) Purpose: monitoring operations of mip6 entities (MN, HA, CN); operational statistics, errors, events Configuring/controling mip6 entities MIB design Greg Daley: Don't have to bind same home address to same c/o address in all cases... CN1 & CN2, you want to communicate with them on two different paths, you want to have entry in table... multiple c/o address to one home address, BU list tells you who you are communicating with; you have no information about that in this table Samita Chakrabarti: What are address types Glen: Here type is address type Greg Daley: Does registered also mean re-registered? Glen: No Q: When you come back home you can de-register. This does not expire. Want to make that distinction? Updated I-D, MIB issues: MIB review guidelines, RFC issues: security considerations Related issues, to be done, implementation Route optimization hint option (Keiichi Shima) Problem statement: MIP6 defines route optimization mechanism, there are no guidelines when to start route optimization Things to be discussed & defined: condition on when to use RO, methods to inform MN about condition. Example of configuration: fire-walled network Q: why not just configure firewall to let packets through? Firewall never blocks response to request. Mobility header. Don't understand what problem you are trying to solve here. Basavaraj Patil: Yes, this is firewall problem. Let's take this off-line. Jari Arkko: Would be better to update firewall. Also, wouldn't it be better to let message get dropped and inform MN there is no RO (if firewall blocks). That's the way the specification currently works. Greg Daley: Other issues than firewall cases? What about latency between MN & CN? You reduce signaling each time you move if you don't have to do RO. Basavaraj Patil: This draft only looks at one instance where RO should be used or not. There are lot more cases, and therefore lot more work that needs to be done on this. Q: Valid problem, but depends whether organization/corporation wants to go to standardization or just reconfigure / solve internally. Roadmap for MIP6 (Gopal Dommety) Home agent reliability Alternate RO schemes MIP for MIP6 Bootstrap for SA between MN & HA Document issues Separate specs for issues such as.... Charlie Perkins: Combine the charter of this WG with mipshop? Gopal Dommety: Out of scope of the roadmap discussion. Q: What are we planning to do with bootstrap? Where is mechanism coming for bootstrap. Basavaraj Patil: We had lengthy discussion in Vienna. Jari Arkko: One thing missing is if you add new home address, setting up policy entrance is not possible. Discussion items (Gopal Dommety) Identity for authentication (NAI) Multi-homing discussion Deployment issues discussion Vendor-specific extensions Authentication of MN to HA without ipsec Looking for people interested in working on bootstrap mechanisms. Acknowledgements: Thanks to Eva Gustafsson and Alpesh Patel for taking excellent meeting notes