Current Meeting Report

2.3.6 IP Routing for Wireless/Mobile Hosts (mobileip)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 05/30/2002

Phil Roberts <>
Basavaraj Patil <>
Internet Area Director(s):
Thomas Narten <>
Erik Nordmark <>
Internet Area Advisor:
Thomas Narten <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: (un)subscribe
Description of Working Group:
The Mobile IP Working Group has developed routing support to permit IP nodes (hosts and routers) using either IPv4 or IPv6 to seamlessly "roam" among IP subnetworks and media types. The Mobile IP method supports transparency above the IP layer, including the maintenance of active TCP connections and UDP port bindings. Where this level of transparency is not required, solutions such as DHCP and dynamic DNS updates may be adequate and techniques such as Mobile IP not needed.

The WG moving forward will focus on deployment issues in Mobile IP and provide appropriate protocol solutions to address known deficiencies and shortcomings. For example, the wireless/cellular industry is considering using Mobile IP as one technique for IP mobility for wireless data. The working group will endeavor to gain an understanding of data service in cellular systems such as GPRS, UMTS, CDMA2000, and interact with other standards bodies that are trying to adopt and deploy Mobile IP WG protocols in these contexts. In order to provide a complete solution and a set of protocols that can be used as a roadmap for widespread deployment, the following work needs to be accomplished by this WG. In the near term, the WG needs to work on:

- Use of NAIs to identify mobile users/nodes.

- Specifying how Mobile IP should use AAA functionality to support inter-domain and intra-domain mobility.

- Develop solutions for IPv4 private address spaces for the scenarios needed for deployment.

- Documenting any requirements specific to cellular/wireless networks.

In the longer term, the WG needs to address:

- QoS in the mobile IP environment using diff-serv and/or int-serv/RSVP.

- Location Privacy.

The Working Group will ensure that solutions proposed for these problem domains are suitable for IPv4 and IPv6 respectively.

Goals and Milestones:
Done  Review and approve the charter, making any changes deemed necessary.
Done  Post an Internet-Draft documenting the Mobile Hosts protocol.
Done  Review the charter of the Mobile IP Working Group for additional work required to facilitate non-host mobility.
Done  Submit the IPv4 Mobile Host Protocol to the IESG as a Proposed Standard.
Done  Submit the IPv6 Mobile Host Protocol to the IESG as a Proposed Standard.
Done  Submit Internet-Draft for NAI support in Mobile IP to IESG for consideration as a Proposed Standard.
Done  Review security framework requirements for Mobile IP.
Done  Review solutions and submit drafts for mobility in private address spaces.
Done  Supply AAA requirements for Mobile IP to the AAA Working Group
SEP 00  Submit the IPv4 Mobile IP Protocol to the IESG for consideration as a Draft Standard.
OCT 00  Review the WG charter and update as needed.
DEC 00  Develop an access technology independent method for supporting low latency handover between access points within an administrative domain or across administrative domains.
JUL 01  Review QoS in a Mobile IP enabled network.
AUG 01  Submit Mobile IPv6 MIB to IESG for consideration as a Proposed Standard.
  • - draft-ietf-mobileip-ipv6-18.txt
  • - draft-ietf-mobileip-reg-tunnel-06.txt
  • - draft-ietf-mobileip-aaa-key-09.txt
  • - draft-ietf-mobileip-hmipv6-06.txt
  • - draft-ietf-mobileip-fast-mipv6-04.txt
  • - draft-ietf-mobileip-lowlatency-handoffs-v4-04.txt
  • - draft-ietf-mobileip-reg-revok-03.txt
  • - draft-ietf-mobileip-qos-requirements-02.txt
  • - draft-ietf-mobileip-lmm-requirements-02.txt
  • - draft-ietf-mobileip-rfc3012bis-03.txt
  • - draft-ietf-mobileip-nat-traversal-04.txt
  • - draft-ietf-mobileip-piggyback-00.txt
  • - draft-ietf-mobileip-aaa-nai-02.txt
  • - draft-ietf-mobileip-vpn-problem-statement-00.txt
  • Request For Comments:
    RFC2004 PS Minimal Encapsulation within IP
    RFC2003 PS IP Encapsulation within IP
    RFC2005 PS Applicability Statement for IP Mobility Support
    RFC2002 PS IP Mobility Support
    RFC2006 PS The Definitions of Managed Objects for IP Mobility Support using SMIv2
    RFC2344 PS Reverse Tunneling for Mobile IP
    RFC2356 I Sun's SKIP Firewall Traversal for Mobile IP
    RFC2794 PS Mobile IP Network Access Identifier Extension for IPv4
    RFC2977 I Mobile IP Authentication, Authorization, and Accounting Requirements
    RFC3012 PS Mobile IP Challenge/Response Extensions
    RFC3024 PS Reverse Tunneling for Mobile IP, revised
    RFC3025 PS Mobile IP Vendor/Organization-Specific Extensions
    RFC3115 PS Mobile IP Vendor/Organization-Specific Extensions
    RFC3220 PS IP Mobility Support for IPv4, revised

    Current Meeting Report

    Mobile IP WG minutes (IETF54 @ Yokohama on July 15th, 2002)

    Meeting minutes captured by Basavaraj Patil and Phil Roberts

    Agenda bashing:

    Mr. Mastaka Ohta requested a presentation slot - rejected by the chairs, ADs asked, and then insisted that the ongoing persistent request be taken offline

    3012bis has actually completed WG last call.
    Actually, it has been sent to the IESG and is on the review list already.

    3220bis is with the RFC editor and should be published as a new RFC soon.

    Reg-Revocation in WG last call now.

    AAA-Keys has completed WG last call and awaiting changes based on IESG review comments.

    MIPv6 discussions

    Resolutions of all issues will be proposed to the ML, with included text for the draft. WG will be able to comment.

    76 - unclear response on whether to include this, asked whether useful, whether not. Dave Johnson requested whether it is dangerous to have it in the text and he and Charlie at least indicated some concern. Some found it useful.

    74 - source selection, plus guidance here, plus implementors common sense will get this right (Hesham).
    Dave J history - acknowledging that it is useful and is there so folks will know it is possible.
    (Mr. Keichi?) some communications must use COA so text will be needed to clarify this.
    (?) Problem needs to be solved, will be done elsewhere, not in this document.
    (Francis) need something like API or state machines for some details and security descriptions.
    (Hesham) in some other API, let's not make it CoA vs HA, but something more abstract.

    62 - (Hesham) separate issue posted to the ML. Some twisted notion of ll home address and needing to keep what's at home.
    (TJ) thinks it ought to be obvious.
    (Francis) should wait for DAD and DIID before deciding on the best solution.
    (Phil) let's go with what we've got
    (Hesham) either defending home address or defending link local
    (Phil) yes, home

    72 - (Charlie) uses same binding update signalling as is in this draft, whereas the fast handover work has new signalling.
    (James) there is signalling for this in the fmip draft.
    (Charlie) Doesn't make sense to use the existing messages to do what it was designed to do?
    (Rajeev) new signalling is slightly different.
    (Charlie) even if you take it out, it could still be done. This provides guidance.
    (Alper) maybe it would be best left where it is to allow better performance now.
    (Erik) the security description is incomplete. (Note to self - work with Jari about what is actually needed to make this complete. If it's a lot, take seriously the request to drop it).

    49 - (Hesham) need to clarify why this is a hard problem.
    (Francis) this is a general IPSEC/IKE problem. Give it to IPSEC to solve.
    (Erik) it is harder than what Hesham said: if I assign myself a temporary address (3041), preferred for a day, deferred for 6 days. Don't want anyone to claim it in the mobility case even though I used it for just a little bit. Hard - need something different. Not tied to binding lifetime, but the lifetime of the temporary address, conflict between multiple mobile nodes trying to claim the same temporary. Conclusion is agreeable to all.

    56 - (FD) HA discovery is totally insecure and there is no way to make it sure.
    (Hesham) It doesn't need to be secure. A fake HA will be discovered immediately.
    (Raj) What is the threat with not securing the HA process?
    (FD) Not sure, but need to use IPSEC and IPSEC will fail. All other proposed solutions can be done in a secure manner.
    (Jim) Was arguing that maybe an alternative is possible, and reducing the size of the doc is a goal. Maybe there is an argument for a special protocol.
    (Hesham) this mechanism serves a good purpose and it should be left in.
    (Dave J) Removing features solely for the purpose of making the doc shorter is a recipe to further reducing the implemented functions.
    (Jari) node requirements can mandate stuff
    (Dave J) node requirements doesn't exist. At worst you create extra work rather than denial-of-service.
    (Thomas) not clear there is a concrete proposal here. Need a concrete proposal if we're going to do something to replace this. Proposal is to keep it, finish discussion on the ML.

    70 - (DJ) what is the purpose in making it mandatory?
    (Jari) when using ESP to protect BUs, ESP doesn't protect source address.
    (DJ) use it only when using ESP?
    (Jari) possible, but introduces unnecessary dependency.
    (DJ) Why not make it a required field? We end up with distinguishing between a BU for home and for non-home BUs.
    (Jari) we already have that.
    (FD) make it mandatory
    (Jari) need to know whether it is ESP. Just make a requirement for home registrations. Don't try to solve an implementation problem by changing the protocol. Let implementors.
    (Hesham) it's not a big problem, don't change it now.
    (Rajeev) in FMIPv6 and HMIPv6 you need it.
    (Charlie) leave it up to implementors
    (Dave J) if you don't know whether you are using ESP you must use this.

    (TJ) dynamic HA discovery question (56). Alternative proposal, if addresses don't fit in MTU, do it j-1 addresses and make j the address of the HA that is responding. Still get first optimization.
    (Charlie) important to keep the first optimization.

    (Hesham) prohibit site-local COA - no text is there.
    (Erik) let's not say anything about site-locals

    80 - (FD) R-bit is needed to say whether mobile node is a router.

    Issues Dave Johnson wants to raise
    (DJ) For RR the MN can't know whether the nonce is too old. An MN can send a BU requesting not to acknowledge. Can't get told nonce is too old. -> Need to be able to handle Binding Acks and match them with sequence numbers even in the case we did not request a binding ack.

    (DJ) For RR, the cookie may be protected by ESP on HA-MN link. If it isn't protected anyone on or near the FL will see both cookies. Why not require ESP on MN-HA link?
    (Jari) Previous discussion led us to believe it is a MAY. One of the reasons is that the kind of attacks that can happen will hurt MN-HA but cannot hurt third parties.
    (DJ) disagrees - affects conversation with CN also.
    (Hesham) thinks it's a SHOULD
    (DJ) wants a MUST, reckless not to take advantage of required fnality

    (DJ) will post rest of issues to list.

    (Mr K) why do all nodes have to support HAO?
    (DJ) for CNs to receive a packet from a mobile node while it is away from home.
    (Mr K) this does not prevent communication.
    (DJ) MN that sends a packet with HAO implies that all nodes must support it.

    Fast Handoff in V6:

    (Phil's pres on an 802.11 fast handoff draft)

    Phil set the context and provided the background for the work and discussion. He also outlined a strategy for moving forward. Phils recommendation is that Fast HO be defined for specific link layers and we can start with defining Fast HO for 802.11
    For details on the proposal refer to the slides.

    - Hesham agrees. However a general protocol is all you really need.
    Jak: Disagrees. Example of IPv6 in RFC2461 and 2464

    Ohta: FMIPv6 useless. Document is large. 3G/FoMA is not valid for Internet access

    Hesham: 802.11 work will raise the same issues all over again

    Jim Bound: Agrees with the process proposed by Phil and supports it

    Gopal: Doing the 802.11 spec will narrow the focus and help Gopal agrees that the 802.11 spec should simply specify the triggers

    Rajeev: V05 already supports implementing FMIpv6 on 802.11

    Hesham: Will the 802.11 draft simply specify the L2 triggers for fast HO?

    Jak: The current draft is focused on Preaddress configuration and this is not possible in 802.11

    (Rajeev's presentation)
    (Jim) on network controlled handover. How does PAR know to send PrRtAdv without an L2 trigger? Only use when there is potentially no L2trigger, when MN sends a solicitation. Assertion: there is no way to do something like this without some kind of l2 info.
    (Hesham) tunnel was previously terminated on the mobile node - now what happens with ingress filtering.
    (Rajeev) question about what's available on L2?
    (Jim) we are setting requirements
    (Rajeev) are we putting musts for L2s
    (Jim) there may be a tight coupling that needs to be specified.
    - had to cut off the pres, Rajeev will post issues to the ML and solicit discussion from the WG on answers to his question.

    VPN Traversal requirements
    (Farid Adrangi presented the requirements)

    (Raj) on RO, is it an objective to solve v4 R.O. (Farid) may
    (Raj) what does RO have to do with this problem? If a new entity is introduced is rt. opt. needed.

    Limited Private Address Support
    (Gabriel's pres) new draft updates guidance for implementation of reverse tunneling
    (Phil) what do you want to do with it?
    (Gab) separate wg document as BCP or Informational
    (Pete) concerned that implementation community is split because there are CDMA vendors who are doing separate implementations from what is done at Cthon. Existing RFC is a fine spec, pp2 understands what it means. Needs to review.

    LMM Requirements
    (Carl pres)
    Some small mods. Ready for WG last call.


    LMM Requirements
    Mobile IPv4 Traversal Across VPN Gateways
    Fast Handovers for Mobile IPv6: Proposed Changes
    FMIPv6 way forward
    MIPv6 Issues
    Limited Private Address Support For Reverse Tunneling In MIPv4