Last Modified: 2004-02-02
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|
Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59 ---------------------------------------------------------- Meeting notes courtesy of: Behcet Sarikaya and Glenn Keeni (Thank you). Monday, March 1 at 1300-1500 CHAIRS: Basavaraj Patil <Basavaraj.Patil@nokia.com> Gopal Dommety <firstname.lastname@example.org> 1. Agenda, Bluesheets, Note takers ********************************** - Some reshuffling of the agenda posted for the WG meeting earlier based on prioritization of work items. - Added Charles Perkins' I-D draft-perkins-mip6-precfgKbm-00.txt to the agenda 2. WG Docs status update ************************ Basavaraj Patil - Base Mobile IPv6 specification moving forward after having been stuck with IANA for a long time. Thanks to Jari Arkko for his efforts to get the IANA issue resolved. The I-D is headed now to the RFC editors queue. - Revision 01 of the MIB document for MIP6 completed. Intent is to go to WG last call mid-April after one more revision. There is also a demo of the current MIB implementation by Glenn Keeni for anyone who would like to see it. - The API I-D has received some comments on the list and also discussed at Connectathon. Will go to WG LC with the next revision. - MIPv6 test suites are at the URL shown in the slides Gabriel: Has there been a WG LC on Pekka Nikander's I-D <draft-nikander-mobileip-v6-ro-sec-02>? Raj: Do not remember. But will check and follow up. The intent is to publish this as an informational I-D. 3. Bootstrapping Problem ************************ Presenter: James Kempf <draft-kempf-mip6-bootstrap-00.txt > - What is dymanic bootstraping? Two things: Dynamically allocating HA and Home network prefix discovery, and dynamically setting up an IPsec SA between MN and HA. Benefits. Enables wider address assignment choices, Better configuration and, Load balancing. Hesham: Dynamic HA discovery does load balancing, not necessarily dynamic HA assignment using AAA. James: Agree. AAA based approach supports new business models, allows nonsubscriber based access. Raj: Bootstrapping should be independent of AAA infrastructure. Jari: But we do need something for bootstrapping. James: One alternative is AAA. Charlie: Why not use DHCP like mechanism that we have here at the IETF-59 venue. Why require AAA? Hesham: Should not mandate AAA. James: Current spec is based on manual keying or IKEv1 SA establishment. Francis: Disagreement with statement on statically assigned addresses in the slides. But ofcourse it just makes life easier. Mobile node does not get the information if the device is switched off. [ E.g. renumbering information]. Old info needs to be maintained. Hesham: The same is applicable in the case MN is un-reachable. James: Benefits include reduced RTT and others. Current support for pushing prefix changes to dormant MNs has drawbacks. TJ: This problem has been discussed. Renumbering should be kept for sometime, dormant mobile has to bootstrap after it wakes up. Raj: Bootstrapping not a solution for the renumbering problem. James: Prefix problem needs to be solved. James: HA discovery uses ICMP and some ISPs disable ICMP. Four bootstrapping scenarios. Out of four 2,3 and 4 are of interest. Conclusion. Dynamic bootstrapping is useful. Current IPsec SA mechanism does not allow dynamic bootstrapping. Greg: Option 2, 3, 4 is of primary scope James: Disagrees Greg: Which security assocs we will we use? What are the scenarios being considered for bootstrapping? Raj: There is a design team that is working on the bootstrapping problem. Scenarios and scope will be further clarified therein. 4. HA reliability problem statement *********************************** Presenter: Ryuji Wakikawa <draft-jfaizan-mipv6-ha-reliability-01.txt> - HA failure. Home link failure. Failure detection, how an MN detects failure. Current base spec is not clear. Service interruption. Recovery? Who initiates recovery. IPsec SA assoc. establishment. Correct ordering, if HA changes, new HA does not know the order. - HA reliability is in current milestones, we need a problem statement. Deng Hui: Round robin load balancing can be used, i.e. redundancy is built into the HA machine. Also reliability can be accomplished by having a multi-blade server type of machine as the HA. Gopal. Reliability solution should be built into the protocol. Hardware solutions are another approach to reliability. Raj. Reliability is a WG charter item. Once we have consensus on the problem statement and scope we will move to solutions. The problem statement I-D will be made a WG item after obtaining consensus on the WG ML. 5. Dual stack Mobile IPv6 ************************* Presenter: Hesham Soliman <draft-soliman-v4v6-mipv4-00.txt> - Problem has been discussed in I-D: draft-tsirtsis-dsmip-problem-02.txt and the discussion today is one possible solution - Problem: MIPv4 and mipv6, IPv4 and IPv6 coexist. If MN uses MIP on a dual stack machine and moves. MN needs to have both. Optimisation overhead. When both mipv4/v6 are used handover signaling, RO signaling needs optimization. Fast handover/LMM signaling. - Proposed solution. Allow each protocol to manage mobility, mipv4 to handle both v4/v6 HoAs to bind to an IPv4 CoA. Draft is about mipv6 as migration tool. Use tunneling to carry ipv4 and ipv6 traffic over the same mipv6 tunnel. Extensions needed to do this. The details are in the draft. One binding update that binds both v4/v6 CoA. Also IPsec SAs. James: Have you implemented? Hesham: no. James. It sounds complicated. IPv6 stack deals with v4 addresses. Hesham: Not really. Pascal: What happens if there are NATs? Hesham: We do not deal with NAT traversal. Greg: Are we talking of static or dynamic allocations, Dynamic allocation of MIpv4 and static allocations for MIPv6 ? Hesham: Bind the HoAV(4 or,6) to my CoAV(6 or V4). (Dual is not MIPv6 or MIPv4 it is IPv4 or IPv6) XYZ: Mipv6 node makes 6to4 address, would'nt that be easier? Hesham. We do not assume that the visited network will provide anything, e.g. 6to4 relay. Create dualstack bindings in mipv6. we need extensions to mipv6. XYZ: NTT runs IPv6 worldwide network. MIPv6 HA can have tunnel server, v6/v4 tunnel, MN in IPv4 network. Tunnel server is known and exists, why not use it? Henrik: Mipv4/v6 to setup these tunnels makes sense. There are commercial deployments. Raj: There is a bar bof tonight at 10pm to discuss this topic further. Pascal: Which mobility solution to use? Raj: We need one mobility solution. It will be mipv4 or mipv6. So this draft is saying use only mipv6. Pascal: Why IETF is proposing two mobility solutions? Raj: You have a solution for IPv4 and another one for IPv6. Its upto you which one you implement/deploy. 6. Issues with firewalls ************************ Presenter: Franck Le <draft-le-mip6-firewalls-00.txt> - Issues listed in presentation. James: Generic problem with firewalls and ESP. Solution is nsis. Jari: Is problem nat or firewall? The solution depends on what. There is nat traversal for IPsec. Frank: Issue is with firewalls. Its the reachability aspect. Hesham: How come you assume BU and BAck will go thru? Franck: We assume creating state in the firewall. Without using ESP. I am assuming ESP issue is resolved some other way. Raj: Problems described here applies to GPRS/UMTS networks as well because GGSN has packet filters similar to firewalls. Xiabao Chen has an I-D that discusses these issues. The I-D is: draft-chen-mip6-gprs-00.txt Franck's draft and Xiabao's drafts are informational documents that are useful from MIP6 deployment perspective.. Question to WG: Firewall issues: Do they need to be documented? Maybe advanced as informational RFC? Go back to ML and discuss. 7. NAI Option ************* Presenter: Kent Leung <draft-patel-mipv6-nai-option-01.txt> James: There is a shared secret key between the HA and MN. We need to have a design team and do things bottom-up instead of pieces. This relates to the bootStrap option. Approximately 3 persons have read the draft. Kent: Yes some issues are related to bootstrapping. Raj: The proposal is to use NAI Kent: There is infrastructure that utilizes NAI. Alper: There are other identifiers, like FQDN, opaque names. Raj: AAA mechanisms deployed today indicate that NAI is a good option. Charlie: NAI in mipv4 is good because IPv4 addresses were not unique, but in MIPv6 they are unique. Why not use network prefix? Why shouldn't we take a network address and use it as an identifier? 8. Authentication Option for MIP6 ********************************* Presenter: Kent Leung <draft-patel-mipv6-auth-protocol-01.txt> - MN-HA authentication function, using NAI for identifying MN. AAA servers identify clients using NAI. Some mipv6 modifications are proposed. Raj: Alternate key mechanisms should not weaken security. BU is secured by somethingelse not by ipsec. James: Key distribution. IKE for key distribution. Draft should talk about a specific key distribution. Raj: This draft assumes shared keys but their distribution is not an issue for this draft. Gopal: Alternative authentication should talk about key distribution? Alper: We should not require additional signaling on MIPv6 that does not exist. Charlie: Base MIPv4 replay protection. We can have better key distribution schemes as time goes on. So requiring key distribution may not be a bad idea. Key distribution can be handled later and or orthogonally. 9. AAA Problem Statement ************************ Presenter: Hiroyuki Ohnishi <draft-ohnishi-mip6-aaa-problem-statement-00.txt> Raj: Integration of MIPv6 with AAA. Additionally AAA can be used for bootstrapping. The AAA WG decided that it is upto mipv6 WG to determine if a MIP6 AAA App is needed. Hesham: It does not look like an integration. John: Another WG like AAA can get work from MIPv6 WG if mipv6 wants it. MSAAA can be done in MIPv6 and then diameter mipv6 application can be done at AAA WG. Jari: Deployments that have AAA and MIPv6 requiring new things at link and netwoprk layer like on 802.11 networks we need to be careful. Raj: This should be an option. Pete: Differentiate access authentication and the use of mipv6. Charlie: Why not use the AAA solution for MIPv4 for MIPv6 also? Raj: Not directly mappable. Since there does not exist the FA. 10. Binding Update Backhauling ****************************** Presenter: Wasim Haddad <draft-haddad-mipv6-bub-01.txt> - Bub reduces signalling. BUBC message is used to agree on bub mode. Eric. In the case where the RR test is done the first time: The first time is it secure? Man in the middle attacks can be done. Bub has this problem, maybe it is more secure but not any more secure. Raj. But Security relies on the esp tunnel between HA and MN. Jari. This is already done in the base spec. Raj. Not enough time to discuss further. The proposal here is an enhancement to Route Optimization when two end-points are mobile. Does this I-D address any security issue that is inherent within the the current RR scheme? 11. Optimizing Mobile IPv6 ************************** Presenter: Wasim Haddad <draft-haddad-mipv6-omipv6-01.txt> Jari: Defining optimization is great. DF RR is good, man in the middle will have only a limited term effect. OMIPv6 might increase the times of effect. Jari feels that there are issues with such an approach. Erik. Agrees with Jari. Latency optimizations are OK but it should like compromise security. Completely getting rid of coti/cot messages not a good idea. Attendee: Bub and omipv6 looks same, what is the difference? Haddad. Bub is for one end point. And it has bubc message. --------------------------------------------------------- With time running out, Raj provided pointers to Charles Perkins' I-D about RO with preconfigured keys. Discussion of this will be taken up on the list. Gopal summarized next steps for the WG.