2.3.8 Mobility for IPv4 (mip4)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-19

Chair(s):
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: www.ietf.org/mail-archive/working-groups/mip4/current/maillist.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
Internet-Drafts:
  • - draft-ietf-mobileip-lowlatency-handoffs-v4-08.txt
  • - draft-ietf-mobileip-vpn-problem-solution-03.txt
  • - draft-ietf-mip4-aaa-nai-02.txt
  • - draft-ietf-mip4-rfc2006bis-01.txt
  • - draft-ietf-mip4-aaa-key-03.txt
  • - draft-ietf-mip4-vpn-problem-statement-02.txt
  • - draft-ietf-mip4-rfc3012bis-00.txt
  • - draft-ietf-mip4-experimental-messages-00.txt
  • - draft-ietf-mip4-dynamic-assignment-00.txt
  • No Request For Comments

    Current Meeting Report

    MIP4 WG Minutes (Monday, March 1, 2004, 1930-2200)

    1. Preliminaries : WG Chair

    (slides: Agenda)

    Minute takers: Pascal Thubert and Jayshree Bharatia

    There were no comments on the agenda.

    2. Document status : WG Chair

    draft status
    aaa-nai In RFC editor Queue
    aaa-key Publication requested
    lowlatency-handoffs Publication requested
    vpn-problem-statement Under IESG evaluation
    reg-tunnel Chair writeup needed
    rfc3012bis Await resolution of one issue
    dynamic-assignment Require one more revision
    experimental-messages Await resolution of one issue
    vpn-problem-solution Review needed
    rfc3344bis Issues resolved but the draft is not published.
    2006 Need mip/mib review and mib doctor review

    3. Update on 3012bis Issue : Pete McCann

    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.

    4. Experimental-messages issue : Alpesh Patel

    (slides: Experimental Message, Extension and Error Codes for Mobile IPv4)

    Issue:

    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.

    Comments:

    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.

    Conclusion:

    It was agreed not to define experimental sub-type. This was determined by the humm in the meeting.

    5. Dynamic Assignment : Alpesh Patel

    (slides: Mobile IPv4 Dynamic Home Agent Assignment Framework)
    Issues:
    1. Add subtype field in Redirected HA Address Extension. This issue is resolved and the solution will be added in the next version.
    2. To align the HA address at 4-byte world boundary. This issue is resolved and will appear in the next version.
    3. The current scheme does not allow dynamic HA registration (AZOA HA address) beyond first registration. The response of this issue was that it makes sense to use AZOA as HA address while dynamic assignment is in progress.
    4. An issue was related to using RRQ with unicast HA address for dynamic assignment. The response of this issue was that for Dynamic HA assignment, unicast HA address will not be used.
    5. In addition to AZOA HA address, provide an extension for additional information to distinguish different cases of dynamic HA assignment. It seems authors require further clarification on this issue.
    6. Editorial issues will fix in the next version of the draft.
    Comments:
    This draft is diverting from 3GPP2 requirements so authors like to know the input on the implication on 3GPP2. Pete mentioned that most of the changes are still essential. It is up to other standards to decide whether they want to adopt the current changes.

    6. Optimized Mobile IPv4 UDP Encapsulations : Farid Adrangi (draft by Sami Vaarala)

    (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.

    Comments:

    • If we take on this, need a charter change.
    • This defines an adhoc header compression for IP header. For VOIP, there are multiple schemes that exist and save more, such as ROHC.
    • ROCH, CRTP, etc also apply to any number of flows. TCP, UDP and RTP compression at the same time. Would be useful to look at the whole architecture. Which are the points where header compression can be used? Endpoints? Middelboxes?
    • The Limit is up to 2 layers for the compression using the current ROHC specification. Need to look at specific cases. But more generic solution is preferable. The next specification of ROHC will handle any number of layers.
    • For the question, why only one CN was picked in the draft, the speaker clarified that it is still for further study. The chair mentioned that the same question was also raised earlier on the mailing list.

    Conclusion: The charter needs to be changed if it is decided to accept this draft. Further discussion is require on this topic.

    7. Fragmentation MTU Extension : Farid Adrangi (draft by Sami Vaarala)

    (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.

    Comment:

    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.

    Conclusion:

    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.

    8. FA Error Extension : Charlie Perkins

    (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.

    9. mobility+IPv4/v6 interworking

    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.

    Slides

    Agenda
    Experimental Message, Extension and Error Codes for Mobile IPv4
    Mobile IPv4 Dynamic Home Agent Assignment Framework
    Optimized Mobile IPv4 UDP Encapsulation
    draft-vaarala-mip4-fragmtu-00 (1)
    Foreign Agent Error extension