2.3.13 Mobility for IPv4 (mip4)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC 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: 2004-10-14


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
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
  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
  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
  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-03.txt
  • draft-ietf-mip4-rfc3012bis-02.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-00.txt
  • draft-mip4-faerr-00.txt

    Request For Comments:

    RFC3846 Standard Mobile IPv4 Extension for AAA Network Access Identifiers

    Current Meeting Report

    MIP4 WG Minutes (Thursday, November 11, 2004, 1300-1500)

    MIP4 WG Minutes (Thursday, November 11, 2004, 1300-1500)

    1. Preliminaries: Chairs

    (slides: http://www.mip4.org/ietf61/mip4-agenda.ppt )

    Minute taker: Eva Gustafsson

    Charlie's presentation regarding 3344bis issues has been moved up, as he has a plane to catch. No other comments on the agenda.

    2. Document Status: Chairs

    draft status
    draft-ietf-mip4-aaa-nai-03 RFC Published
    draft-ietf-mip4-aaa-key-06 RFC Ed Queue
    draft-ietf-mobileip-lowlatency-handoffs-v4-09 AD Evaluation :: AD Followup
    draft-ietf-mip4-vpn-problem-statement-03 RFC Ed Queue
    draft-ietf-mip4-rfc3012bis-02 Almost ready to be sent to IESG
    draft-ietf-mobileip-reg-tunnel-09 Draft with new boilerplate, then IESG
    draft-ietf-mip4-dynamic-assignment-03 Publication Requested
    draft-ietf-mip4-experimental-messages-02 RFC Ed Queue
    draft-ietf-mip4-rfc2006bis-01 Review needed
    draft-ietf-mobileip-vpn-problem-solution-03 Editing needed
    draft-ietf-mip4-rfc3344bis-01 ID exists
    draft-mip4-faerr-00.txt In WG last call

    3. 3012bis - summary of recent issues, status, next steps: Pete McCann



    3012bis, issue raised with HMAC_CHAP_SPI, proposed solution to delete HMAC_CHAP_SPI from text, i.e. no longer supported.



    4. Resolving outstanding issues for 3344bis, and next steps: Charlie P.

    ( slides: http://www.mip4.org/ietf61/rfc3344bis.ppt )


    Issue 45 remains unsolved - what to do if deregistration message fails due to broken foreign-home authentication extension. New revision specifies that FA MUST NOT apply foreign-home authentication extension to MN's deregistration request.


    Kent Leung:
    Thought we had different agreement on mailing list.
    Pete McCann:
    Agreed that if FA-HA authentication failed, extension must be discarded. (?)
    Hesham Soliman:
    If anything added on top, needs to be authenticated to avoid man-in-the-middle attack.
    If extension is there, it needs to be respected.


    Question by someone on different issue...

    Need to take this discussion to the list again.
    Henrik Levkowetz & Pete:
    Ok to only do this when care-of address was that of another FA, not the FA transmitting this to you? Check lifetime zero, other care-of address, FA would leave on authentication extension?
    Need to think this over...
    Exception on FA not to put this on, on HA not to discard.
    Simultaneous bindings?
    Charlie Perkins:
    Don't see connection with simultaneous bindings.


    Action item: Charlie will write this down and send to list

    5. Co-editor for draft: Henrik


    We still need a co-editor to help Sami Vaarala with this. Those interested, please approach chairs after meeting.

    6. Faerr document - last call status Pete McCann


    Last call ended Friday, Nov 5th . One comment received: what does MN do if receives unauthenticated FA extension?


    Since this message only goes on link local between FA and MN, should not be too troublesome to leave as is. TTL check in this message? Think so.
    Resolution of wording done in WG? Yes. Should get FA error on MN. Case of MN-FA link being compromised minimal. Need text about MN-HA connection.
    Need text describing that FA does if it sees this from FA. Should deregister. Be careful; not authenticated.
    Either go "MAY", or do the ping test first.
    Make sure HA does not deliver erroneous message, right?
    No guarantee that message actually came from HA.
    If you get FA error, calls for suspicion, wait a little longer for successful registration reply, otherwise do something about it.
    Thinks this is overengineering it. Why dance around this particular one? Just take it for what it is and act on it. Assume link between MN and FA is safe.

    7. Take up route optimization for MIPv4?: Pete McCann


    Old problem. Do we want to take this up in the WG?

    Earlier statement that there is considerable work to get acceptable security.

    Would like to see some real-world deployment. Which are the customers, what is the security model, assumptions?


    You got the right question. Also, first question should be "what do you mean by route optimization?". If it's the same as for MIP6, if we apply same security requirements, will be a challenge. Old draft, signaling between FAs would be useful, more useful than full-fledged route optimization.
    Would like to keep signaling orthogonal to existing signaling.
    Think we should do this, not to have all traffic go through HA. Nokia would like this.
    What link layers? Carrier?
    For all environments...
    We need to pin down what environments need this.
    Alexandru Petrescu:
    Certain type of route optimization is useful. Is there common idea what this leads to and what solutions we want to work on?
    Old draft (Perkins, Johnson), also MIP6 type of solution.
    We run and deploy MIP4, see no need for route optimization. Whatever we see for MIP6 will be deployed. To enable service, not needed. For efficient mobility, FA-FA signaling needed.
    James Kempf:
    We don't deploy MIP (4 or 6). Agree with Hesham; we don't need route optimization now.
    Low-latency handoffs helpful. Experience says most efficient solution would be low-latency stuff plus hierarchical stuff. We effectively get route optimization with this.
    Get real customers to come forward so that we can nail down requirements for this.
    Please post studies etc. on mailing list. Also, doing this in our WG requires discussion with ADs to put it on charter.
    We need some more support for foreign agent error to move forward.


    Humming inconclusive.

    8. Questions about MIPv4/MIPv6 - IPv4/IPv6 transitions: Henrik


    MIP4/MIP6 combinations. New mailing list created: miptrans@ops.ietf.org < mailto:miptrans@ops.ietf.org >.

    draft-larsson-v6ops-mip-scenarios-00.txt ... describing scenarios evolved. Will be submitted as individual submission, as there is currently no WG where it belongs. If you have interest in this area, read draft and comment.

    To do MIP4 work in this space, we need clear statement of scenario and environment where you need your solution to be applied, clear statement of which combinations (from draft-larsson...) will be addressed, and definition of problem (why does this need to be done?).

    We need to know why we are doing it and how it will apply.


    First time I see draft-larsson...
    Submitted recently, mentioned it because we want people to look at it and comment.
    Example: MIP6 MN transmitting to IPv4 network?
    Yes, this scenario is one of many mentioned in this draft. Would belong in MIP6 WG or possibly in new transition WG.

    9. Adapting MIPv6 Fast Handover for MIP4: Charlie Perkins


    FMIPv4 motivation and design ideas, implementation benchmarks. Available for anyone to work on - will not push this.


    Could you post something about similarities with low-latency on the draft? We need discussion with ADs if we want this back on the charter.
    Only two factors: performance and simplicity.
    Curious on the numbers. Is there a further breakdown on those numbers...?
    Numbers due to advertising model.
    This is basically fast handoff for MIP6, low-latency. Hard to find difference enough for so significant difference in performance.
    We wanted answers as fast as possible.
    Very interesting. First two values I recognize from client I used to work on. Would like to see as experimental.
    Agree with Henrik. We have a paper where we did extensive comparison. We also did something similar to this; worked very well on WLAN.
    Can you send pointer to paper to the list.
    Will do as soon as it is published.
    Would be really good to see just email on difference between this and low-latency.


    IP Mobility Support for IPv4, revised