2.3.13 Mobility for IPv4 (mip4)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. 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-10-03


Peter McCann <mccap@lucent.com>
Henrik Levkowetz <henrik@levkowetz.com>

Internet Area Director(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Margaret Wasserman <margaret@thingmagic.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.

MIPv4 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
MIPv4 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 MIPv4 NAI RFC (2794) will be revised
to reflect implementation experience

2. Work items that are pending from the previous Mobile IP WG, which
will be completed by the MIP4 WG, are:

- completion of the MIB for the revised base Mobile IP
specification (2006bis)

- regional registration draft.

3. The MIP4 WG will also complete the work on MIPv4 interactions
in VPN scenarios. This work will involve identifying the requirements
and a solution development for MIPv4 operation in the presence
of IPsec VPNs.

4. Additionally, a proposal has been made for how MOBIKE could work
together with MIPv4. This proposal does not describe any new protocol,
but formulates a best current practice for deploying MOBIKE together
with MIPv4. The working group will adopt and complete this document.

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.

6. It has been proposed that the FMIP protocol, which has been
standardised for MIPv6 in the MIPSHOP working group, should also be
published as an experimental protocol for MIPv4. A draft for this
exists. The working group will take up and carry this work forward
to publication

7. An extension to carry generic strings in the Registration Reply
message has been proposed. The purpose is to supply supplemental
human-readable information intended to the MN user. The working
group will complete the specification and applicability statement of
such an extension.

8. RADIUS attributes for MIP4. A set of RADIUS attributes has
been proposed for MIPv4.

The working group will first produce a requirements specification,
describing how the work differs from the requirements in RFC 2977
and the functionality provided by RFC 4004 (the MIPv4 Diameter App).
The reason why this first step is required is that RFC 3127 pretty
clearly shows that full 2977 functionality can't be provided by even
a considerably extended RADIUS, so we need to match the requirements
to what can be done within RADIUS.

Provided the requirements work finds approval with ADs and radext,
the workgroup will complete the specification of MIPv4 RADIUS
attributes, solicit feedback from the Radius Extensions WG, adjust,
and submit this for publication.

9. MIPv4 Extension for Configuration Options.

Several drafts have proposed extensions to help improve configuration
of MIPv4 clients. The latest proposal is for a general configuration
option extension which could carry information such as e.g., DNS
address and DHCP server address. The working group will take on
and complete one proposal for a configuration option extension.

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 2005  Revised MIPv4 Challenge/Response (3012bis) to IESG
Jan 2005  Regional registration document to IESG
Feb 2005  Revised rfc2794bis (NAI extension specification) to the IESG
Apr 2005  Revised MIPv4 specification to IESG for Draft Standard
Jun 2005  Revised MIB for MIPv4 to IESG
Sep 2005  MIPv4 VPN Solution to IESG


  • draft-ietf-mobileip-lowlatency-handoffs-v4-11.txt
  • draft-ietf-mip4-rfc3012bis-04.txt
  • draft-ietf-mip4-dynamic-assignment-06.txt
  • draft-ietf-mip4-rfc3344bis-02.txt
  • draft-ietf-mip4-vpn-problem-solution-02.txt
  • draft-ietf-mip4-faerr-02.txt
  • draft-ietf-mip4-reg-tunnel-00.txt

    Request For Comments:

    RFC3846 Standard Mobile IPv4 Extension for AAA Network Access Identifiers
    RFC3957 Standard Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4
    RFC4064 Standard Experimental Message, Extension and Error Codes for Mobile IPv4
    RFC4093 I Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways

    Current Meeting Report

    Mobility for IPv4 WG (mip4)

    Mobility for IPv4 WG (mip4)

    THURSDAY, November 10, 2005, 1300-1500


    Henrik Levkowetz <henrik@levkowetz.com>

    Pete McCann <mccap@lucent.com>


    1. Preliminaries 10 min Chairs

    • Minutes
    • Agenda bashing

    No comments on agenda

    2. Document Status 15 min Chairs


    New revision submitted right before the meeting. Next: Chair writeup and publication request

    Charlie submitted a new version before the meeting. One request for a new error number was done.
    submitted the weekend before the deadline but it has been on the website for a month and there has been no change.
    the target is draft standard?
    we had some subsequent technical changes therfore we need to recycle to proposed.
    Henrik: Yes, we had indicated draft standard but people need to be
    aware that we have done changes.

    Vijay: not exactly sure what changes were made?

    Ready for WG last call
    Waiting for AD Go-Ahead::AD Followup
    Waiting for AD Writeup

    AD Evaluation::Revised ID Needed

    This draft has an Appendix which the authors don't agree on how to handle. We've had an independent review of the Appendix too, and need to decide what to do with it.

    Had a long and painful story. We may be splitting up the draft into an appendix and the main part and then do the appendix as informational.

    Waiting for AD Writeup

    Several reviews done for AD, Need to decide whether to fork off the Generalized Mobile IP Authentication Extension as a separate draft.

    Henrik: Jayshree is doing the few changes..

    IESG Evaluation::AD Followup

    (Just re-submitted by Karim, ready to go to RFC Editor)

    Henrik: has been approved.
    MIP-centric review done, new revision needed
    Kent is going to do the review alone or with help. Hopefully ready for MIB doctor.

    draft-ietf-mip4-experimental-messages RFC 4064

    draft-ietf-mip4-vpn-problem-statement RFC 4093

    Henrik: that is nice.

    3. New charter 5 min Chairs



    Did not get to the IESG slate. No indication of negative results. If you have comments, this is your last chance. We have a new work items that will make into charters. Until that is cleared, we will not take new work items. There are some presentation are here for addition to the charter but that is the bottomline at this point.

    4. New WG drafts: 20 min Author

    Status summary, open issues:

    draft-bharatia-mip4-gen-ext 5 min Kent


    Presentation by Kuntal.

    The draft aims to send conf info from HA to the mobile during the initial exchange.

    Changes from -00 to -01 is formatting of configuration parameter based on DHCP options, no longer MIP-specific

    Also allows the MN to request config info from the home or visited network and that at the same time if needed.

    Here we reuse DHCP codes so you don't have to define new subtypes. Adopted the DHCP option code structure and formatting.

    received some comments on the mailing list and updated the draft based on that.

    A generic extension to be used for the method was shown, including type, length, entity-type (distinguishing between FA ad HA), and config data (conf parameters are packed here).

    an exampel of config parameters were shown.

    open issues:only DHCP based parameters are considered. Do we have to define non-DHCP parameters?

    You may also need a default realm for DNS queries.
    You can basically piggyback DHCP info with this.
    Can we define this as DHCP-only information and if we need non-DHCP we define a different extension for that later.
    good idea
    DHCP option length
    If all the option are going to fit in one or multiple NVSE.
    We have talked among ourself on what to do with the DHCP versus non-DHCP, we think we should built that at subtype level rather at type level.

    Henrik: either way works for me.

    draft-devarapalli-mip4-mobike-connectivity 5 min ???



    Presented by Vijay:

    Brief update from 00 to 01:

    01 has been submitted with not many changes, some based on Jari and TJ's reviews.the target is going to a BCP doc. some additions on when this mechanism is used. the idea is use this for IKEV2. and IKEv1 reference was removed.

    draft-sastry-mip4-string-extension 5 min Kent



    Presented by Kent:

    Update since version 00:

    update to 02 some changes regarding the revocation messages. Changes on the use of message string extension, correction to security considerations. Some changes based on TJ's comment and addressed most of the issues.

    Can we have some comments? it seems to be pretty straight forward and should go to last call.

    draft-nakhjiri-radius-mip4 5 min Madjid



    Presented by Madjid:

    Update since version 01:

    Clean up of the attribute section.

    Review from Jari Arkko. There was a question on why the registration request was being hashed. this was to avoid the attribute size issue in the future if the reg. req gets too big.

    Diameter can tell whether you are dealing with a HA or a FA. for RADIUS you can do this only by some information in the attributes. Something new is needed. A new MIP-Agent type

    Some work remaining. More details on Diameter AVP-RADIUS attribute translations

    Issue with MN-AAA authenticator and MFCE. please fix 3012bis.


    Don't agree with CCoA mode calculation in 3012bis draft
    Discusses already on WG. Folks agree there are 2 solutions in RFC 3012.
    Take it to the WG alias.
    We've had quite a bit of discussion with RADEXT chair and need to make clear what we are doing here and how we separate that from what it is done in Diameter. There should be a doc on this.

    draft-koodli-fmipv4 5 min ???

    Nothing to go over here.

    5. IPv6 over MIPv4 and MIPv4 over IPv6. 5 min Chairs

    Taking on some work in this area has been discussed earlier, during IETF-62. The question has been raised by some people again, in view of the work on MIPv6 over IPv4 and IPv4 over MIPv6 which is being done in the MIP6 working group.


    Authors have asked to reconsider this again. He likes to ask for a HUMMM on which way to go. No decision is to be done here.
    The aim is to allow the operator to do IPv6 over MIPv4 and a similar work is done in MIPv6.

    Kent agrees.

    I like to discourage these sort of things in general. It is better to move on to IPv6 rather to do run things this way.
    Not everybody agrees plus there are specific cases that you simply cannot do it.
    Philosophically is better not to force people on these things.
    Rajeev K:
    questions what is the relation between this and the traversal work in MIPv6.
    this only deals with MIpv4 and not MIPv6 and that is why.
    the goal is to use one signaling protocol.
    chair hat off, I submitted this draft a while ago. It makes sense IPv6 over MIPv4.
    personal experience. Operators are willing and want to move to IPv6.
    we are not proposing people to not move to IPv6 here. for information only how many people want to take this or not to take this on. The HUMM for for is stronger than the HUMM against.
    Scope of work?
    Both drafts.
    Related drafts:



    1. GRE Key Extension for Mobile IPv4 10 min Parviz


      GRE (Generic Routing Encapsulation) [ RFC 2784 ] is one of the encapsulation formats permitted by RFC 3344. GRE may use keys to distinguish different tunnels from each other. [RFC 2890]. This draft proposes a MIPv4 extension to communicate GRE keys between MIPv4 tunnel endpoints when requesting GRE tunnelling for MIPv4 traffic.

      Parviz presented.

      3344 optionally supports GRE tunneling. The proposal is to allow this tunneling.

      there is a need for subscribers who are home in 3GPP. YOu cannot really distinguish between traffic streams based on HoA, CoA. So we need a new extension.

      The idea is to allow both HA and FA to assign different keys (assymetric).

      There are situations that these keys can be available to HA and FA.

      But in 3344 the MN can set the G bit. Here we should be able to based on policy overwrite the G-bit setting and request a GRE tunneling.

      Henrik: clarification, we are talking about GRE key, not encryption key.

      Mohan: is it for FA CoA or colocated mode

      Parviz: no for both.

      This is for FA CoA mode only.

      Parviz: the HA can assign two addresses to the same subscriber because it is private addresses.

      back to presentation: GRE key assgnment is outside of the scope. The behavior of FA is new, the G-bit overwriting is not the in RFC. The impact is that key allocated by the FA can be used for FA-to-HA use.

      No changes to the MN behaviour.

      Questions/ comments/ working group item?


      good idea. When HA is wholesale, this is a good idea. Today the only solution is to have different instances of HAs.


      I like the idea, it is done 3GPP2. But not comfortable with G-bit overwrite.


      the final decision is by the HA and the HA can reject and finally have a different tunneling.


      what happens to MN-HA-AE if you can the G-bit?


      G-bit in the GRE extension is not changed.


      why would the MN care whether you are GRE or not? why does have to be based on MN request.


      when the tunnel is between FA and HA, what is the role of MN? this is breaking the paradigm of the 3344.


      consistent. The extension is added by the FA.


      which entity should assign those keys, FA or HA or both.


      both. the key that FA wants to receive should be specified by the FA and the one HA wants should be assigned by HA.


      Unidirectional and bidirectional should be supported. HA should be able to assign the keys for both sides.


      can't see a use case for when we want the HA to allocate both.


      receiver should allocate the key.


      agree, it is ok for the HA to allocate the key, technically.


      may simplify what FA wants to do, but does not simplify the FA code.


      don't think implementation pov either way is harder.


      should we really have to have both optoins in the draft.


      proposing to have the receiver assign the keys.


      Agree with everything but it does not hurt to add it and make it optional.


      how does the FA know what sort HA is it talking to.


      Kent to propose some text and take it to the list.

    7. Generic Notification Message for Mobile IPv4 10 min Hui


    This document proposes a protocol enhancement that allows Mobile IPv4 entities to asynchronously send and receive explicit notification messages. The Registration Revocation mechanism of RFC 3543 could have been specified using a message such as the one proposed here, had it been available at the time.

    Presented by Hui


    in some cases, there is a need for MIPv4 entities to send and rx asynch notification events during a session. 3344 does not provide specification for this.

    This doc defines generic message and notification model for this process.

    does not define specific notification extensions.

    some examples are presented.

    HA initiates a notfication to MN, FA initiates a notification to MN, another case.

    Generic notification msg send by mobility agent to inform another mobility agent or a MN.

    3 flags were defined

    flag A, bit identifies if ack to the notification msg is need. other fields of the message were defined.

    issues: to discuss whether a notification MUST be acked and whether the use of flag is good or not.

    issue 2: R bit in Agent advertisement

    usage examples were presented:

    registration revocation, asynch. user notification (out of credit, coming service interruption), asynch MN or agent notification, may be necessary for high availability scenarios with long reg. life times.

    comments on the issues and the general idea
    similar in MIP6 regarding HA switch. I think this is a good idea, but I am struggling with the use cases and who will be doing this. Why would you notify the HA when the system is going down, and create more traffic.
    Just one BS with access channel in cellular won't cause that much traffic.
    you are not sending 1 Million notification, it is good idea to cover in the draft for planned maintenance, when you notify that you want to take the HA down in so and so hour.
    still you may have thousands of MNs maintained by HA, still that is a lot of messages.
    This a small subpercentage of the overall traffic.
    why not use reg. revoke. why this one?
    Are you supposing that we should do this using another message? don't agree.
    reg. revoke is done today.
    make this optional, not mandatory.
    We should put our foot down and say no if we think something is causing a lot of problem (personal opinion).
    3GPPX wants to use SIP SDP for this.
    not sure I can see the use case scenario for this.
    the real scenario is HA switch.
    don't focus on where it is used, but focus on whether this is useful or not. example is prepaid.
    last comment on prepaid and people use text messages for that purpose. HA has no business sending notification to the MN when account is up. for MN-FA notifications you would need specific bootstrapping methods. If something is already solved in the industry we don't try to go and design a new solution.
    right now the revocation only goes to FA, but not to the MN, so it may not be the right way to do it but we do have a MN-HA association. In deployments people don't completely shut doewn the HA anyway, but if you want to do that more power to you.

    8. Mobile IPv4 Fast Handovers for 802.16e networks 5 min Junghoon


    IEEE 802.16e is an amendment of 802.16 ("WiMAX") which extends it from fixed terminals only to fixed and mobile operation. This document describes how Mobile IPv4 Fast Handover can be used IEEE 802.16e link layers.

    Presented by Junghoon.


    rfc 4068 is a work item (FMIPv4), so he proposes fmipv4 over 16. some of related work is done in MIPshop, so he is mentioning. some mobility is done in layer 2. predictive and reactive (??) modes were discussed.

    Is there interest in this work? is this a topic for this working group?

    the problem is that FMIPv6 over X is supported in MIPSHOP, but they have strict charter on v6. Should we get into FMIP stuff here?
    True, may be it should be here.
    why just 16e? should be FMIPv4 over anything?
    you need to take the specifics of the link to make it working.
    it is good stuff.
    it is interesting.
    I can predict problems down the line when we want to go for publication.

    9. Using multiple interfaces for increased throughput 5 min Srinivasa


    This document defines enhancements that allow a MN, when away from home, to simultaneously use multiple connected network interfaces so as to obtain higher aggregated bandwidth.

    Author is not here. it is interesting work. uses multiple interfaces to stream videos to remote villages in India because the existing cellular systems and it is actual deployment. It is mature for adoptions. As an example of what you can do in a multiple interface scenarios.


    MIPv4 configuration extension
    MIPv4 Message String Extension
    MIPv4 Radius Attributes
    MIPv4 - Mobike interaction
    MIPv4 GRE extension
    MIPv4 Notification Message
    MIPv4 - FMIPv4 over IEEE 802.16e
    MIPv4 - Using multiple interfaces for increased throughput