Last Modified: 2004-02-19
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|
MIP4 WG Minutes (Monday, March 1, 2004, 1930-2200)
Minute takers: Pascal Thubert and Jayshree Bharatia
There were no comments on the agenda.
A couple of options were presented in the last meeting to resolve an issue on indicating an error to the MN by the FA upon receipt of the Registration request from the HA. These options are whether to overwrite the HA's error code or to insert a new error code extension at the FA. The later option was preferred in last IETF meeting which also introduces a dependency on perkins-faerr...
Charlie clarified that this was the reason MIP4 working group decided to have the new draft (perkins-faerr) so this dependency is justified. This implies that a new reference document need to be added to the RFC3012bis draft. The issue and proposal will be posted on the mailing list soon.
There is one issue unresolved for this draft at this time. The issue is whether to define an experimental sub-type. Adding new sub type provides advantage such as implementation will need minimal code change from experimentation to standardization. If this subtype is not defined then the same functionality will be achieved using experimental extensions. It introduces a disadvantage of reserving sub-type number from allocated numbers.
It was clarified that the format of the extension are already defined in 3344. Pete pointed out that it doesn't make sense to do at this time. It should be done case by case basis.
It was agreed not to define experimental sub-type. This was determined by the humm in the meeting.
(slides: Optimized Mobile IPv4 UDP Encapsulation)
The motivation is to minimize MIPv4 data packet overhead when UDP encapsulation is used and most of mobile node's data traffic is destined to one particular correspondent node. The applicability is on MIP/VPN or basic IPSec-over-MIP4 and also VoIP over MIP. The idea is to specify an extension to be used in congestion with RFC 3519 to enable overhead extension. A scenario was explained with extension "Preferred-CN".
In this draft, a new state "preferred" CN is defined in the mobility binding based on from the new extension. A new flag is also defined in the MIP Tunnel data Message header indicating optimized UDP encapsulation in use. Examples of how packet processing works (inbound and outbound) were discussed in brief. The author asked working group opinion on whether this is something which can be standalone or it is viewed as an extension of RFC3519.
Conclusion: The charter needs to be changed if it is decided to accept this draft. Further discussion is require on this topic.
(slides: draft-vaarala-mip4-fragmtu-00 (1))
Large packets are sometimes dropped by routers. This seems like a realistic deployment issue. Solution is to define an extension with preferred MTU for reception. MN and HA sends MTU independently. Applies to both IP-IP and IP-over-UDP. This work may be proceed as a stand-alone or an extension to RFC3519. This draft focuses only on the tunnel between the HA-MN.
There was a question on the use of solving only one leg of the route. It seems solving this cases would solve majority of the cases according to the author.
It seems not many people have read the draft. Further discussion will be on the mailing list. The charter may need to be changed if adopted as a WG draft.
(slides: Foreign Agent Error extension)
This draft was written to solve the problem of RFC3012bis but the problem is generic. The problem is that the FA doesn't have any way of indicating the error to the mobile node in the successful Registration received from the HA. For this, a new faerr extension has been defined. This extension is added to the Registration Reply whenever there is a need to indicate an error. This draft is very short and going to WGLC as soon as it appears in the Internet Draft repository. this draft will be referenced by RFC3012bis.
Experiments being carried out to support MIPv4 nodes roaming in IPv6 networks and MIPv6 nodes roaming in IPv4 networks. Several proposals for how to do this exist.
Henrik proposes a (non-)bar BOF to discuss the need for it.