2.3.7 IP Routing for Wireless/Mobile Hosts (mobileip)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-19

Gabriel Montenegro <gab@sun.com>
Phil Roberts <proberts@megisto.com>
Basavaraj Patil <basavaraj.patil@nokia.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <erik.nordmark@sun.com>
Internet Area Advisor:
Thomas Narten <narten@us.ibm.com>
Mailing Lists:
General Discussion: mobile-ip@sunroof.eng.sun.com
To Subscribe: mobile-ip-request@sunroof.eng.sun.com
In Body: (un)subscribe
Archive: http://playground.sun.com/mobile-ip/
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-21.txt
  • - draft-ietf-mobileip-reg-tunnel-07.txt
  • - draft-ietf-mobileip-aaa-key-11.txt
  • - draft-ietf-mobileip-hmipv6-07.txt
  • - draft-ietf-mobileip-fast-mipv6-06.txt
  • - draft-ietf-mobileip-lowlatency-handoffs-v4-04.txt
  • - draft-ietf-mobileip-reg-revok-05.txt
  • - draft-ietf-mobileip-qos-requirements-03.txt
  • - draft-ietf-mobileip-rfc2006bis-01.txt
  • - draft-ietf-mobileip-lmm-requirements-03.txt
  • - draft-ietf-mobileip-rfc3012bis-04.txt
  • - draft-ietf-mobileip-nat-traversal-07.txt
  • - draft-ietf-mobileip-piggyback-00.txt
  • - draft-ietf-mobileip-aaa-nai-05.txt
  • - draft-ietf-mobileip-vpn-problem-statement-req-01.txt
  • - draft-ietf-mobileip-mipv6-ha-ipsec-03.txt
  • - draft-ietf-mobileip-vpn-problem-solution-00.txt
  • Request For Comments:
    RFC2005 PS Applicability Statement for IP Mobility Support
    RFC2004 PS Minimal Encapsulation within IP
    RFC2003 PS IP Encapsulation within IP
    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
    RFC3344 PS IP Mobility Support for IPv4

    Current Meeting Report

    efforts.Minutes for IP Routing for Wireless/Mobile Hosts WG (mobileip)
    Monday, March 17 at 1300-1500
    CHAIRS: Basavaraj Patil <Basavaraj.Patil@nokia.com>
        Phil Roberts <PRoberts@MEGISTO.com>
        Gabriel Montenegro <gab@sun.com>
    Minutes by Nick Moore (sharkey@zoic.org) and Hesham Soliman 
    (hesham.soliman@era.ericsson.se) with additional notes and edits by 
    Abbreviations used:
    BA = Bernard Aboba
    BP = Basavaraj Patil
    CP = Charlie Perkins
    Erik = Erik Nordmark
    HS = Hesham Soliman
    JA = Jari Arkko
    JK = James Kempf
    MT = Michael Thomas
    TJ = TJ Kniveton
    TN = Thomas Narten
    1. Agenda and WG Document Status            10 Mins
    MIPv6 - last call completed IESG review (discussions ongoing)
    MN - HAsec: going to IESG
    AAA NAI: completed IETF LC
    Reg Rev: completed IETF LC
    WG LC:
    RFC 3012bis
    AAA keys for MIPv4
    regional registrations : dormant
    Low latency: To go for Exp, no further progress since Atlanta
    LMM req: ready for WG LC
    Looking for security advice for VPN DT output (problem and solution 
    - Suggestions for 
    draft-mccann.mobileip-80211fh-01 (informational?)
    - MIPv6 RO background (ionformational?)
    - New draft in dhc WG for MIPv4 (take a look)
    MIB status -- in the revision to 3044, would the associated
    MIB go to draft standard?
    TN: no, it advances like any other, going forward as PS.
    CP: regional regs is not dormant, there were good comments from alan 
    o'neill and these were incorporated.
    So there has been some progress.
    Gabriel: If all the updates were made, we will look into it.
    2. Mobile IPv6 - IETF LC issues update            30 Mins
        o draft-ietf-mobileip-ipv6-21.txt        [15]
    draft-ietf-mobileip-mipv6-ha-ipsec-03.txt [15]
        (Jari Arkko, Charles Perkins)
    Jari on remaining issues.
    273 - can a HA be CN at the same time?
    Suggestion: ignore a new BU with a different H value
    Hesham: This seems like a bug in the MN, maybe an error message should be 
    CP: I would like to suggest the same.
    MT: Should CN->HA actually be illegal or is there a real situation where 
    this could occur.
    JA: Could always delete the old entry before sending new binding.
    JA: It's clear that this is an error condition.
    277 - what should CN do if H=1?
    Proposal: Clarify that RR be used if and only if H=0, and Silent discard if 
    RR not used as expected.
    No comments. Suggestion seems acceptable
    279 - NS src addr from HA to figure out the MN's addr
    Proposal 1: start answering NSes after sending the BU
    Jari: I prefer proposal 1
    ??: agree with proposal 1
    TJ: I also agree
    Issue 281 IESG Technical comments:
    Technical: different issues, no problem here.
    Issue 281 IESG Security comments:
    IKE should be a SHOULD; some work required.
    TN: needs to be a discussion, security people need to describe _why_ it 
    should be a SHOULD.
    MT: Should not be mandatory on IKE, but on some flavor of key mgmt 
    (there's others besides IKE like kink). Not necessary to single out IKE.
    BA: IKE will only work with IKEv1 cuz only aggressive mode could be used 
    (main mode), and then the handling of fragmented packets won't work, ikev2 
    won't fix this, you end up with 1/8 of a key mgmt
    CP: sequence number already does replay protection for several years 
    (potentially) using preconfigured keys.
    278 - movement detection
    HS: proposal #1 (ignore the issue) is reasonable and simplest, No point in 
    complicating these algorithms now.
        A MN can change CoA based on new prefix or ll address change.
    JK: agree
    Ed Remmel: R-bit should be a MUST not just for HA's but for all routers
    Charlie: The solution is different depending on the link type. No one size 
    fits all.    A mandated solution could hurt performance on some media It 
    would be a lot better to leave it as is.
    TJ: I agree with everything said so far. Now is not the time and place to 
    fix this.
    Erik: If people implement this from the spec and doesnt work then it would be 
    useful to mention the problem in the spec to reduce the probability of 
    errors in stacks.
    TJ: Are there common cases where routers configure the same ll address on 
    different interfaces?
    Erik: If there is one then that's enough.
    Vijay: Some implementations use Eager switching and some don't. There are 
    many different ways of doing this.  There is no need to fix this in the 
    spec. Some warnings are enough. Perhaps the new MIP WG charter should 
    address this.
    BP: This needs in a different doc. From this discussion I would say leave it 
    as is and document the problem.
    3. Connectathon Update on Mobile IP protocols           10 Mins
       (Samita C.)
    All implementations supported rev 20.
    2 implementations supported IPsec between MN and HA based on WG draft.
    A discussion for MIPv6 Internet testing. A mailing list will be setup. 
    Presenatation at www.connectathon.org.
    no major issues, just simple clarifications
    currently resolved
    TJ: there were also 3 implementations on prefix discovery on home link. 
    First time this was interop tested and it was successful.
    4. Registration Revocation in MIPv4 - LC issues update  15 Mins
        o draft-ietf-mobileip-reg-revok-05.txt
        (Steve Glass)
    No questions asked.
    5. Mobile IPv4 Traversal of VPN Gateways update         15 Mins
        (Gopal Dommety, Sami Vaarala)
    Gopal on vpn design team
    Problem statement essentially done
    MT - do any of your solution allow an IPsec tunnel to replace the MIP 
    ip-in-ip tunnel?
    Gopal - we don't do this cuz you'd need the HA in your DMZ
    MT - so? in that particular situation it would be beneficial
    Gopal - it's implicitly allowed, yes.
    ? - how does this mesh with nat traversal?
    Henrik: If you wrap the IPsec tunnel in the MIP tunnel then it will work 
    through NAT. They are two different things that can work together or by 
    CP: It's always been possible to put IPsec with IP in IP tunnelling.
    Gopal: We assume no protocol changes
    Charlie: Why can't the HA put IPsec over the tunnel?  It was never 
    prohibited in RFC 2003. You can already do that without protocol changes
    Gopal: MIP is terminated at the VPN GW
    Charlie: But you could also terminate it at the HA
    Henrik: What Charlie suggests is resonable if you have a VPN GW with a HA 
    together in one box.
    Charlie: Ok, so no protocol changes are needed.
    ? - how much is applicable to ipv6?
    Gopal and BP - not currently targetted, this is ipv4 only work
    6. Fast Handovers for Mobile IPv6 - Issues              10 Mins
         (Rajeev Koodli)
    tunnel establishment hi/hack only after processing fbu
        less state to keep
    revised fna
    issue: how to secure FBU
        depends on trust MN-PAR
    MT: What is the difference between MN-HA security association and MN-PAR 
    relationship anyway? Why the different mechanisms?
    JK: Possible answer for this by ending tunnel in NAR, needs further 
    HS: Why we can't use IKE: address ownership problem. CGA's would work, 
    otherwise it's hard
    Alper: Roaming node may need many trust relationships maybe use SEND 
    Rajeev: must be a solution in the FMIP draft.
    CP: Two cases: how do you set up associations, how do you transfer 
    JK, HS: Draft can't advance until security at least referenced.
    Erik: Maybe as _experimental_ without security.  Maybe it's possible to 
    build a shared secret to authenticate MN to PAR communications.  via 
    7. Optimistic DAD and Non-Predictive Handovers          15 Mins
        (Nick 'Sharkey' Moore)
    Erik: Will the router override send packets to the optimistic node if an 
    entry already existed for anothe node?
    Nick: Based on experiments I found that it will continue to send packets to 
    the old node, not the optimistic node.
    Thomas: There is a problem with a packet sent to foo and received in 
    another node then that node might RST the TCP connection
    Nick: It won't happen, the node does not override an exisiting entry.
    James: How do you get Fast RA if you don't have L2 triggers?
    Nick: Fast RA just means answering the RS without delay.
    BA - good papers on arbaugh on delays caused by scanning, but l2 
    on802.11 now seen as little as 40ms
    Hesham: So is it fair to say that the difference between predictive and 
    non-predictive handovers is the L2 handovers?
    Nick: Yes.
    Charlie: Did you use 400ms with piggybacking mode?
    Nick:..... missed it
    Charlie: Is there something that needs to be specified in the 
    piggybacking draft.
    Nick: If you don't have outoging traffic then piggybacking can be 
    Erik: So do you assume that the delay to the MAP is zero? I.e. the MAP is 
    close to the MN?
    Nick: Yes we assume that the MAP is pretty close to the MN, which is true in 
    many cases. Maybe not all.
    Rajeev: So you still have some packets going to the old AR till the BU 
    arrives at the MAP?
    Nick: Yes that's right.
    8. Extension to Sockets API for Mobile IPv6             10 Mins
    Samita on 
    No comments
    Alper on draft-yokote-mobileip-api-01.txt
    There is an IPR statement on this draft but it will be removed in the next 


    Design Team Update
    Connectathon 2003 - Interoperability Testing Report
    MIPv6 Base & HA Security
    Mobile IPv6 Fast Handovers
    Mobile IP API
    Mobile IP WG Doc Status
    Mobile IPv6 Advanced Socket API Extensions
    Non-Predictive Handovers
    Next Steps in IP Mobility (NSIIM)
    Optimistic DAD
    Registration Revocation in Mobile IP