2.3.15 Mobility for IPv4 (mip4)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional MIP4 Web Page

Last Modified: 2005-02-09


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

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 be revised
to reflect implementation experience.

2. A mechanism for home agent assignment at the time of mobile-ip
rather than preconfigured for the mobile node, has been proposed.
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.

3. 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
- completion of the MIB for the revised base Mobile IP
specification (2006bis)
- regional registration draft.

4. 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 VPNs.

5. Some issues have been raised with respect to RFC3519. These will be
identified and addressed as appropriate, through errata, revision
of RFC 3519, and/or supplemental documents as needed.

Other potential work items may be identified in the future but will
require an appropriate re-charter.

Goals and Milestones:

Done  AAA Keys for MIPv4 to IESG
Done  MIPv4 VPN interaction problem statement to IESG
Done  Low latency handover to experimental
Done  Dynamic Home Agent assignment protocol solution to IESG
Jan 05  Revised MIPv4 Challenge/Response (3012bis) to IESG
Jan 05  Regional registration document to IESG
Feb 05  Revised rfc2794bis (NAI extension specification) to the IESG
Apr 05  Revised MIPv4 specification to IESG for Draft Standard
Jun 05  Revised MIB for MIPv4 to IESG
Sep 05  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-03.txt
  • draft-ietf-mip4-rfc3012bis-03.txt
  • draft-ietf-mip4-experimental-messages-02.txt
  • draft-ietf-mip4-dynamic-assignment-03.txt
  • draft-ietf-mip4-rfc3344bis-01.txt
  • draft-ietf-mip4-vpn-problem-solution-01.txt
  • draft-mip4-faerr-00.txt
  • draft-ietf-mip4-reg-tunnel-00.txt

    Request For Comments:

    RFC3846 Standard Mobile IPv4 Extension for AAA Network Access Identifiers

    Current Meeting Report

    MIP4 WG Minutes (Thursday, March 10, 2005, 1645-1745)

    MIP4 WG Minutes (Thursday, March 10, 2005, 1645-1745)

    1. Preliminaries: Chairs

    Minute takers: Espen Klovning, Jayshree Bharatia, Will Ivancic

    Henrik: Pete McCann could not be here so I am on my own here.

    Henrik had not received slides from Vikas Goel and therefore dropped his presentation of draft-goel-mip4-encapext-00.txt

    Vikas asked whether he could to add the presentation to the agenda. Henrik allocated a slot at the end of the agenda.

    2. Document Status: Chairs

    draft status
    draft-ietf-mip4-dynamic-assignment-03 Waiting for AD Writeup
    draft-ietf-mip4-faerr-00 Waiting for Chair Writeup
    draft-ietf-mip4-reg-tunnel-00 AD Evaluation



    Henrik: This is the third WG meeting where I have asked for volunteers to do MIB review, but we still don't have anyone.

    Kent: We should try to leverage the MIPv6 MIB resource. The MIPv6 MIB draft went through quickly

    Reviewer needed for MIP-centric review of
    draft-ietf-mip4-rfc3012bis-03 Waiting for Chair



    Henrik: There is one remaining issue with 3344. It is the same as last time. The discussion is going on but no consensus yet. I hope to manage that now.

    One remaining issue
    draft-ietf-mip4-aaa-key-06 Published as RFC 3957
    draft-ietf-mip4-experimental-messages-02 RFC Ed Queue::Awaiting processing and publ.
    draft-ietf-mip4-vpn-problem-statement-03 RFC Ed Queue::Awaiting processing and publ.



    Thomas Narten: There is a nominal dependence on the regional tunneling draft that is holding up the low latency draft.

    AD Evaluation::AD Followup



    Henrik: I have one reviewer for the VPN solution draft lined up but more are needed.

    Review needed

    3. Resolving one outstanding issues for 3344bis: Charlie P.


    Slides: http://tools.ietf.org/wg/mip4/ietf/62/fa-ha-sa-selectors.pdf

    This issue revolves around what selectors (e.g., Reg. Request CoA and HA address) should be used to select the SA (security association) used to calculate FA-HA Authorization-enabling extensions.

    Issue: Selector for the HA-FA Security Association.

    • When the MN sends a de-register request to a foreign agent with the intention of de-registering its earlier binding it had with a different foreign agent, the behavior of FA in RFC3344 is to reject such request with invalid care-of address error. However, the HA considerations allows such requests. The scenario is not handled consistently at both HA and FA ends.
    • Also, if the foreign agent is allowed to forward such requests, there is no explanation as how the home agent should locate the security associations for that FA and validate the FHAE.
    • This issue was also discussed in IETF-61. The following are the selector fields: - Source IP address - Destination IP address - Care-of address - Home address - Lifetime field (or the bit which says that it is zero or not) - The D bit (to determine whether coa is co-located).

    It was mentioned that CoA and HoA usage may be problematic because there will not be correct security association in those cases.


    Kent Leung:

    Agreement was that we are not considering NAT scenario (out of scope for RFC3344). Also, SA (indexed by the source IP address) would solve the problem. This source address will always be known by the HA.
    Referred to as a,d here.
    Agreed to go with that approach. Just gone use IP src to index cover all the case. It been awhile.
    It would be nice to find a solution for the non-NAT case. We will have to revisit NAT case too. We must be aware of that now. Permitting COA MN to send directly.
    It was brought up but it is breaking some processing rules. It is the R bit case right. We will not be able to go over this now. We should start from our email discussion.
    We have no known starting point.
    We are probably too tired to discuss it
    I did run out of steam.. We were at equilibrium


    I do not mind any good approach. We have not found it yet.
    What is your view of the status?
    What I stated earlier was the status.
    We need a known starting point. I had hoped we had come to a point where we could agree.
    I can summarize how far we have come.

    Action item:

    Kent to summarize how far this communication has gone. The working group will consider this as a new starting point. Note that there was no resolution offered on this issue. There will be further discussion on the mailing list.

    4. Generic Strings: Alpesh Patel


    Slides: http://tools.ietf.org/wg/mip4/ietf/62/genericstring.pdf

    This document specifies an extension to carry a text string in the Registration Reply messaged, with the purpose of having the text string displayed on the Mobile Node user interface.

    Alpesh presented the draft that stems from customer requests during deployment.

    • This draft defines a new skippable extension for use by HA and FA in registration request. Note that both FA and HA can add this extension in to the same registration request.
    • A new subtype defines two values indicating who adds this extension. If this extension is added by the HA, it must be present before MHAE.
    • In case of authentication failure, error is returned. The text field of the extension can be displayed on MN's user interface. The MN may throttle the message.


    Espen Klovning:

    The mechanism is OK but I do not like the reference to user interface. The MN might not have a user interface. It could write the string to a log. Tone down the reference to user display. It is up to the MN to decide what to to with the information.

    Avi Lior:

    I like the draft. In case of AAA, user doesn't know the detail. Although it is not clear how to indicate whether the string should go to the user or not.


    I agree with Espen. It is up to the MN to decide what to to with the strings.


    This can be appended by both nodes in the same message. If FA adds this extension, it can't be authenticated (which is optional).


    This is within the scope of this WG but will require a charter update.


    Enough interest (humming) to make this a WG item

    Charter update will be proposed by the chair for this work.

    5. Host Configuration Extensions: Kent Leung


    Slides: http://tools.ietf.org/wg/mip4/ietf/62/hostconfig.pdf

    This document describes the extensions used to provide the base host configuration in the Registration Request and Reply messages.

    Kent presented:

    • The MN needs additional configuration to setup MIP interface. This is from the deployment perspective. Current host configuration is insufficient.
    • Defines NVSEs in the registration Request used by HA to include DHCP in response. Host configuration types includes HA prefix, DHCP server, DNS server, DHCP client ID, default Gateway, DNS suffix and config URL.
    • The informational status is asked at this time by the author. Again, this will go as vendor specific option.


    It wasn't very clear whether WG should take this document as a WG item or not. Although 6 people volunteered to support this draft if it is taken as a WG item.

    6. Questions about MIPv4/MIPv6 - IPv4/IPv6 transitions: Chairs


    There are currently 4 proposed solution drafts for MIPv4/MIPv6 transition. One for MIPv4 and three for MIPv6. The drafts describes different alternatives. It is not clear where this work belongs to at this time. Non of the solution are complete. I think we should start by producing a problem statement.

    Show of hands indicated little interest in the WG for taking the transition issue up as a WG item.



    Surprised over the lack WG interest. Charter WG to have clear idea. Current deployments of MIP4 that wants to go to IPv6.


    There are two distinct scenarios of interest, One for a MIPv6 node to reach the IPv6 network over IPv4, and the other for people who currently have MIPv4 deployed but would like to move to MIPv6.


    Too many access network with IPv4. That is the reason for the interest in MIPv6.

    Thomas :

    Ok, so the first scenario would fit better in the MIP6 working group.

    6A. Questions about regional registration and AD feedback: Chairs



    There is a small issue on how to handle AD review feedback. Charlie?


    We will be able to answer all issue that has been raised by the ADs. We should have a new draft shortly after the beginning of June.

    7. RADIUS attributes for Mobile-IP v4: Madjid Nakhjiri


    Slides: http://tools.ietf.org/wg/mip4/ietf/62/radius_mip4.pdf

    This document defines the RADIUS attributes that provide support for Mobile IPv4 operations such as key management and authentication services during a mobile node's registration process.

    Madjid presented the draft.

    • This draft is relevant to MIP-AAA interaction. A receipt of the registration request results in to the authentication and creation of new security association. There is no document detailing this information from the AAA perspective. All current documents are written w.r.t. MIP. Two cases are considered, co-located and FA-based CoA.
    • Can't do Radius extension unless this WG endorse this work. Hence Liaison is needed from MIP4 to RADEXT WG.
    • Want to make sure that MIP functionality is verified by this working group.


    We have due to deployment requirements made vendor specific solutions that do the same. There is interest for this.


    There is definitely deployment interest.

    Avi Lior:

    We have to review the semantics of the attributes. View whether RADIUS protocol is violated. Perhaps WG item. Primarily, ask Radius to review it.


    When I worked on MIPv4 deployments, we did our own. Having a standardised set will be good. This will be a WG item for RADEXT. They need to know how we evaluate this, though.


    It defines new attributes. Then the right home is the RADEXT WG. It does not matter. Both WG must be happy with the solution.


    We need to think about 3012bis in this. Only MD5 is supported in 3012bis. RADIUS have limitations. There are no mechanisms to use HMAC or SHA1, and MD5 is being deprecated in RADIUS group.


    This should be standardized in RADEXT working group similar to what has been done for DIAMETER.


    Agree with Avi. We have to look at the semantics of fields. It should be decided by MIP experts. After consensus we should go through RADEXT WG to get approval.


    Humming indicated that the WG should invest energy in this document. Although the decision on where it will land as a wg item is still open.

    8. Known bugs in 3519: Sri Gundavelli

    RFC 3519

    Slides: http://tools.ietf.org/wg/mip4/ietf/62/3519-bis.pdf

    Experience with RFC 3519 and discussions around rfc3344bis has brought to light some weaknesses of RFC 3519 which may warrant starting work on a revision of this. This presentation will give a summary of these issues.

    Sri presented a few issues/problems with RFC3519 that have been detected during implementation and deployment.

    • The motivation for this draft is to present different issues which are related to RFC3519 and found from the implementation.
    • Issue 44: According to RFC3344, the FA is required to send a registration request with the source address of the outgoing interface. This conflicts with RFC3519 where the FA is required to set the source address of the registration request to its CoA.
    • Issue 45: HA dependency on the source address for the NAT detection logic.
    • Issue 3(?): Keep-alive message. This has no protection. This is causes inconvenience.
    • Issue 4: Usage of ICMP echo packet format for the keep-alive message and the associated issue. Protocol package, the context should be maintained (either MIP subsystem or something else)
    • Issue 5: Overloading the MIP port 434 for control and data messages and the implementation issues. Need to identify whether this is a data or control packet. This is just a UDP package and goes all the way to the application layer.
    • Issue 6: FA doesn't have any role for request but the reply is not the same. It may be of different version which may cause problem.


    I am fine with all the issues except the one where the port number can be done in kernel. No bis issue. Another protocol.


    The problem with 3519 is that the same channel is used for both signaling and data


    This is an router/hardware performance issue that is less relevant for client implementations.


    Suggest to make 3519bis an WG item. Henrik will serve as editor and got commitment from 5-6 people to contribute to this draft.

    9. Encapsulation extension: Vikas Goel


    This drafts describes an extension which allows the Home Agent to specify, in the Registration Reply, the kind of encapsulation types it supports.

    Vikas presented a draft to address a scalability issue with tunnel endpoints in the where the HA should force the MN to use a specific tunnel encapsulation.



    This will not work as long as the M and G bits are not mandatory in RFC 3344.


    You have to set up three tunnels for each HA. It will not scale.


    This is not necessary. The RRQ can not indicate more than one tunneling method.


    Yes, you can.


    What is the original intent? There is no way for the HA to know what to use. Deployment scenario should be well understood.


    HA just reacts on what is selected by the MN. But if it is different from what HA wants, there may be a need of supporting two encapsulation choices.


    Don't see a clear need. This makes sense only if HA supports either G or M. It doesn't make sense if HA supports both. Generally clients are not deployed which are incompatible with HA. This doesn't seem like a real issue since num of choices are few only.


    Encapsulation offer goes in a registration request and the selection of the encapsulation is received in the registration reply. Hence there may not be any need of having multiple tunnels.


    The proposed solution may not work properly.


    RFC 3344 is not very clear but the general trend is that HA selects the capability sent in the registration request (appendix of RFC3344 indicates this way).


    Vendor specific extension may be the solution.


    I read the specification before the meeting and it says you can. It is not very clear in the specification, though, so it seems that this is an new issue for 3344bis


    It was determined that RFC3344 needs to have further clarity on encapsulation information negotiation. And, hence, there may not be any problem which need to be solved by this draft.

    Henrik: We are done.


    FA-HA Selectors
    Generic Strings
    Host Config.
    Radius Attrib.
    RFC 3519 bugs