Last Modified: 2004-07-13
Mobile IPv4 is currently being deployed on a wide basis (e.g., in cdma2000 networks). The scope of the deployment is on a fairly large scale and accordingly, the MIP4 WG will focus on deployment issues and on addressing known deficiencies and shortcomings in the protocol that have come up as a result of deployment experience. Specifically, the working group will complete the work items to facilitate interactions with AAA environments, interactions with enterprise environments when Mobile IPv4 is used therein, and updating existing protocol specifications in accordance with deployment needs and advancing those protocols that are on the standards track.
Work expected to be done by the MIP4 WG as proposed by this charter is as follows:
1. MIPv4 has been a proposed standard for several years. It has been adopted by other standard development organizations and has been deployed commercially. One of the next steps for the WG is to advance the protocol to draft standard status. As part of advancing base Mobile IP specs to DS, the Mobile IPv4 NAI RFC (2794) will also be progressed towards DS.
2. Key exchange using AAA infrastructures for setting up security associations defined in RFC3344 will be completed.
3. The AAA WG, which is currently dealing with the Diameter Mobile IP application, requires the AAA NAI for Mobile IPv4. This work will be completed by the WG. The MIP4 WG will also work with the AAA WG to ensure that the Diameter Mobile IP application is aligned with WG requirements.
4. Home agent assignment at the time of mobile-ip registration, rather than preconfigured for the mobile node, has been proposed in draft-kulkarni-mobileip-dynamic-assignment-01.txt. The WG will take on the task of completing this. The ability to switch the home agent assigned to a mobile node while registered will also be considered as part of this task.
5. Work items that are pending from the previous Mobile IP WG, which will be completed by the MIP4 WG, are RFC3012bis (Challenge-response mechanism), low-latency handover draft to experimental status and the completion of the MIB for the revised base Mobile IP specification (2006bis).
6. The MIP4 WG will also complete the work on Mobile IPv4 interactions in VPN scenarios. This work will involve identifying the requirements and a solution development for Mobile IPv4 operation in the presence of IPsec VPN's.
7. Experimental message types and extensions for Mobile IPv4 in accordance with draft-narten-iana-experimental-allocations-03.txt has been proposed in draft-patel-mobileip-experimental-messages-01.txt. The work group will take on and complete this specification.
Other potential work items may be identified in the future but will require an appropriate recharter.
Done | AAA Keys for MIPv4 to IESG | |
Done | MIPv4 VPN interaction problem statement to IESG | |
Oct 03 | Revised MIPv4 Challenge/Response (3012bis) to IESG | |
Oct 03 | Advance RFC 2794 (NAI Extension specification) to IESG for Draft Standard | |
Done | Low latency handover to experimental | |
Nov 03 | Revised MIB for MIPv4 to IESG | |
Dec 03 | Revised MIPv4 specification to IESG for Draft Standard | |
Jan 04 | Dynamic Home Agent assignment protocol solution to IESG | |
Jan 04 | MIPv4 experimental extensions and message draft to IESG | |
Feb 04 | MIPv4 VPN Solution to IESG |
RFC | Status | Title |
---|---|---|
RFC3846 | Standard | Mobile IPv4 Extension for AAA Network Access Identifiers |
MIPv4 Meeting Minutes
--------------------- Overview from the chairs Henrik: Is there a need to follow the VPN problem solution draft Can MobIKE solve the problem Requires upgrade of the VPN. Kent: Problem statement is trying to leverage the existing infrastructure Mobike might be addressing other problems Vijay: Mobike solves a specific problem. Gopal: We need to follow the VPN problem solution. This problem is important and we need to address it Kent: Mobike can it solve the problem ? Vijay: The problem that mobike solves is not the same as what we are addressing Charlie: Mobike is misnamed. Lot of questions were raised on the Mobike ... Henrik: I'm not opposed to this problem statement Ashutosh: Telecordia has some implementation on this ----------------------------------------------------- FA Error Extension draft - Charlie Kent: When is the extension added by the FA. [??]: The Alpesh: 3344 does it mandate the MHAE as the last extension ? Charlie: No. Kent: Will the FA modify the error code. Sri: The draft needs some guidance as when this extension needs to be used Pete: Yes. The draft needs to add more text ------------------------------------------------------------ 3344bis draft - Charlie Charlie: Issue 45 needs to be resolved We had some long discussions in the mailing list Kent: We cannot disregard the FHAE for dereg messages. Charlie: We are registering against the will of the MN Pete: We still need to allow FHAE to be validated Kent: MN deregistering a given COA is supported in the base draft and we still need to allow that Henrik: Some one needs to provide some text for resolving this. Kent: The last provided text is good Charlie: Pl. We can add some text ---------------------------------------------------------------- IPv4 Dynamic NAI based Home Address Assignment - Kent ??: What do you put in the capable extension ? Clarification on the extension ? Kent: Explained the contents Pete: This is very good work. This can be potentially the wg item. If we send 2794 to drafts standard, then we should move these changes to 2794bis Vidya: In MIP6 wg, I heard lot of comments on NAI extension Pete: In v4, we had NAI for a long time and carriers have deployed it. I hope MIP6 group will come to the same conclusion. NAI is becomming the global identifier. Vidya: NAI as defined is not defined as a device identifier. Now, we are using it that way. Is that ok. Pete: This is a MIP4 group and so that discussion is specific to MIP6 ---------------------------------------------------------------- Home NAI Extension - Henrik Henrik: Sri: If there are multiple interfaces on the home agent and if both Home Agent and Foreign Agent are running on the device, if a mobile node moves across the interfaces, what NAI will the Home Agent advertise ? Henrik: NAI is subnet specific. The home agent has to advertise a different NAI per subnet Sri: For deployments that may not be such a good idea. Configuration will be difficult In the security considerations, the draft says this improves the security. If there is a malicious node advertising fake IRDP messages, we are forcing all mobile nodes on that LAN to believe that they are at home and thus forcing them to deregister Henrik: Mobile nodes believe that they are at home only after a successful deregistration Kent: clarfification on IRDP numbering space ? Henrik: Kemp: Doesn't sound right to me Can make use of DHCP Is this extended to foreign agent Brigesh: My credentials are validated by the network Henrik: I want to detect it fast Brigesh: From RADIUS, you can get extra attributes Henrik: New option needs to be added to DHCP to solve this problem This will help you detect in milli second latency Brigesh: If you need the service, Gab: Henrik: The scenarios you are referring to are in v6 ? Gab: yes --------------------------------------------------------- Pete: Update on new charter items Sri: What is the status of the FA Identity Draft we published ? Will it be a WG item ? Pete: We can have that discussion in the mailing list We have to see if that can be addressed in the Henrik's Home NAI draft Sri: The difference is the Home NAI draft has the realm information and what we need is the Host Identifier Pete: Sure ------------------------------------------------------- |