2.3.13 Mobility for IPv4 (mip4)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://www.mip4.org -- Additional MIP4 Web Page
NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-07-13

Peter McCann <mccap@lucent.com>
Henrik Levkowetz <henrik@levkowetz.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>
Internet Area Advisor:
Thomas Narten <narten@us.ibm.com>
Mailing Lists:
General Discussion: mip4@ietf.org
To Subscribe: mip4-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/mip4/index.html
Description of Working Group:
IP mobility support for IPv4 nodes (hosts and routers) is specified in RFC3344. RFC 3344 mobility allows a node to continue using its "permanent" home address as it moves around the internet. The Mobile IP protocols support transparency above the IP layer, including maintenance of active TCP connections and UDP port bindings. Besides the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns such as optimization, security, extensions, AAA support, and deployment issues.

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.

Goals and Milestones:
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
  • - draft-ietf-mobileip-lowlatency-handoffs-v4-09.txt
  • - draft-ietf-mip4-aaa-key-06.txt
  • - draft-ietf-mip4-vpn-problem-statement-02.txt
  • - draft-ietf-mip4-rfc3012bis-02.txt
  • - draft-ietf-mip4-experimental-messages-01.txt
  • - draft-ietf-mip4-dynamic-assignment-02.txt
  • - draft-ietf-mip4-rfc3344bis-00.txt
  • Request For Comments:
    RFC3846StandardMobile IPv4 Extension for AAA Network Access Identifiers

    Current Meeting Report

    MIPv4 Meeting Minutes

    Overview from the chairs

    Is there a need to follow the VPN problem solution draft Can MobIKE solve the problem Requires upgrade of the VPN.

    Problem statement is trying to leverage the existing infrastructure Mobike might be addressing other problems

    Mobike solves a specific problem.

    We need to follow the VPN problem solution. This problem is important and we need to address it

    Mobike can it solve the problem ?

    The problem that mobike solves is not the same as what we are addressing

    Mobike is misnamed. Lot of questions were raised on the Mobike ...

    I'm not opposed to this problem statement

    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

    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 ?

    Explained the contents

    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

    In MIP6 wg, I heard lot of comments on NAI extension

    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.

    NAI as defined is not defined as a device identifier. Now, we are using it that way. Is that ok.

    This is a MIP4 group and so that discussion is specific to MIP6

    Home NAI Extension - 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 ?

    NAI is subnet specific. The home agent has to advertise a different NAI per subnet

    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

    Mobile nodes believe that they are at home only after a successful deregistration

    clarfification on IRDP numbering space ?


    Doesn't sound right to me Can make use of DHCP Is this extended to foreign agent

    My credentials are validated by the network

    I want to detect it fast

    From RADIUS, you can get extra attributes

    New option needs to be added to DHCP to solve this problem This will help you detect in milli second latency

    If you need the service,


    The scenarios you are referring to are in v6 ?



    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


    IPv4 Dynamic NAI-based Home Address Assignment