Current Meeting Report
Jabber Logs

2.3.5 IP Routing for Wireless/Mobile Hosts (mobileip)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 08/08/2002

Gabriel Montenegro <>
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-03.txt
  • - draft-ietf-mobileip-lmm-requirements-02.txt
  • - draft-ietf-mobileip-rfc3012bis-03.txt
  • - draft-ietf-mobileip-nat-traversal-05.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

    IETF55 Mobile IP WG meeting
    November 19th, 2002 (1930 - 2200)
    Basavaraj Patil
    Phil Roberts
    Gabriel Montenegro
    Thanks to Alper Yegin and Samita Chakrabarti for contributing these 
    meeting minutes.
    Agenda and Document Status
    Meeting agenda presented by Basavaraj. Introduced the new co-chair 
    Gabriel Montenegro to the WG.
    WG document status presented by Phil Roberts
    1. The WG is currently working on advancing RFC3344 and RFC2794 to DS. 
    Interop data has been collected.
    2. IESG approval for the MIPv4 NAT traversal I-D has been received and 
    should be on the RFC-ed queue soon.
    3. Mobile IPv6 draft 19 has been released. AD comments have been 
    received by the WG.
    4. WG last call completed on the following I-Ds: 
        - rfc3012bis, 
        - AAA Keys,
        - QoS requirements (this I-D has been handed off to the NSIS WG),
        - regional registration for Mobile IPv4 (authors addressing last call 
        - registration revocation for Mobile IPv4 (awaiting AD comments), 
        - FMIPv4 (experimental) and 
        - MIPv6 and IPSec HA-MN interaction (comments being addressed by 
    5. WG I-Ds ready for last call:
         - LMM Requirements
         - AAA NAI for Mobile IPv4
    6. Work in progress
         - Mobile IPv6 I-Ds, FMIPv6 and FMIPv6 for 802.11 , HMIPv6 and LPAS 
    Mobile IPv6 issue status and discussion
    Jari Arkko and Charles Perkins
    Status as of draft version 19:
    - All issues resolved
    - HA-MN IPSec was produced
    - Comments received from AD- will go to last call soon
    - 102 Issues (12 rejected, 90 adopted, 6 major issues, 30 minor, 30 
    medium, 24 editorial)
    New issues have been filed since AD comments were received
    Primary focus on AD comments at this meeting.
    Issue 163: Run MLD between the MN and HA. Text has been proposed and 
    agreed on the mailing list
    Issue 159: D bit semantics: who should be responsible for knowing when to do 
    DAD? Proposal: remove the D bit, and let the HA initiate
               DAD unless deregistration or defending the home address. 
    Agreed on the mailing list. 
    Issue 156: Conflict with ND and DAD 
               Proposal: Produce a separate doc on optimistic DAD
    Issue 158: When to start RO
               Recommendation: Produce a guide line when to start RO by the MN, 
    this guideline will/should be a result of experience gained with 
    experimentation  and interop testing 
    Basavaraj: it depends. If CN has no binding, no RO even after you move.
    Erik: If CN already had state (binding cache), you want to 
    immediately update after movement. This case should make a 
    Thomas: there are a lot of things to think about "when to do RO".
    You might want to give some guidelines.
    Issue 160: HA discovery should not assume single address of a HA
               Proposal : Let DHAAD  return all addresses of  each HA
    Issue 150: Failed de-reg when returning home (addressed )
    Issue 157: Address collision action 
               Disable the interface and wait for reconfiguration when DAD 
    fails. This is a drastic action. Where to fix this action? At SEND WG? 
    Should we update IPv6 ND spec? Or, MIPv6 spec? No consensus on the 
    mailing list. 
               RFC2462 says disable interface and wait 
               (drastic action for Mobile situation)
               Options discussed:
                1) Let SEND deal with this
                2) Generate private address (RFC3041) when address 
    collision happens 
                Comments: What if SEND and non-SEND nodes are on the same 
    subnet ?
                        Malicious case: Can't do much unless it is 
                        Normal collision: Rarely happens, is it worth 
    worring about ?
               Folks seem to prefer option 2) for MIPv6 case.
    Issue 154:  ND constant tuning differs from ND 
    	    1) Let IPv6 wg change ND doc and remove reference from MIPv6
    	    2) Write a separate draft 
    	    3) Both above
    There has been long discussion on this topic. Mostly working group 
    members are in favor of not removing the MIPv6 specific ND constants from 
    the base draft  as they are quite important for MIPv6 operation. ADs  
    recommended a separate draft. Dave Johnson suggested that keep the 
    information in the MIPv6 doc now and remove later when alternate 
    document is available. Otherwise the information could be lost. 
    Chairs supported this idea. 
    Charlie P.: cost of modifications are not needed for all routers, just for 
    those supporting mobile nodes. We can have documents that people can 
    implement and get good results.
    Bob Hinden: these changes are fairly generic. Let's bring them back to IPv6 
    WG, as extensions to ND. It's not a special case, it's a normal case. 
    Jari: most routers will have to do these.
    Hesham: link-layer indications are not generic. Also, all routers need to 
    implement these, as a router may serve mobiles at any time.
    James Kempf: there are things that are specific to mobile nodes, not all 
    nodes will be mobile node. Wireless links are different. 
    Charlie P.: it's a tunable parameter. It's a mistake to bury tunable 
    parameters in another document.
    Greg Daley: I don't have opinion on which document should cover these. It's 
    MIP's responsibility to look after these issues. It should be done in MIP 
    Basavaraj: if frequency increased, what's the problem here?
    Erik: One issue: how frequently sent unsolicited RAs? Other issue: how 
    frequently can they sent solicited RA? It makes sense to talk about 
    applicability of these things. 
    Brian: we can even add new options, but why can't we change existing ones?
    Thomas: these changes need to be reviewed by the IPv6 WG. We can get an 
    updated doc. in 6 months. 
    Gabriel M.: what if IPv6 WG not like it?
    Thomas: either way. they can oppose it during the last call. 
    Thomas: I think these apply to all nodes. Split up things.
    Dave Johnson: We discussed this at the IPv6 WG. It was approved. Now it's 
    being re-opened. Why the consensus established is no longer valid.
    Also 6 months is too long. And 6 months is not accurate.
    Thomas: consensus depends on the last calls.
    Basavaraj: this WG believes 50ms is the right time. This WG made a 
    decision. Now we are speculating the IESG last call might have 
    problems. This is speculation. Everyone at the IETF will have a chance to 
    review this at the last call.
    Erik: modular specification is better. If we had realized that earlier, we 
    could break MIP spec into several protocols, home agent discovery, etc..
    Bob Hinden: IPv6 WG is your friend. 
    Bob Hinden: Router builders won't see this spec. 50ms makes me nervous.
    In productization, adding more features in a product slips the release 
    Charlie Perkins: this is a well understood technique.
    Jim Bound: products can slip, but not for 6 months.
    Phil Roberts: there might me more than this comment during the last call.
    This group of people prefers to leave it in.
    Thomas: please clarify what things will be left in.
    Phil R.: only advertisement interval.
    Thomas: how about the wait before sending solicited RA?
    some people: both.
    Greg: fastRA proposal should be handled separately.
    Decision: RS/RA intervals as specified now will be in MIPv6 draft 
    although they differ from ND doc at the moment. 
    Issue 151:  MIPv6 and DHCPv6 
                -Does it work ? If MN follows DHCPv6 spec, does it get a 
    DHCPv6 address assigned by HA ?
                 Question: Does it need to be fixed before last call ?
                 Thomas: MIPv6 should not preclude DHCPv6, at least an 
    investigation should be made if MIPv6 protocol is able to handle DHCPv6 as it 
    is or upon minor enhancement. 
    Issue 162:  Site-local addresses - should we allow it ?
    - Currently only on disconnected sites. Will update after ipv6 
    site-local discussion. 
    Mike: is the main issue with route optimization?
    Charlie: initial discussion was about what addresses are legal in 
    routing headers.
    Mike: a compromise might be to forbid RO with site-locals.
    Bod Hinden: just use gloabl for now, wait for IPv6 to decide.
    Charlie: this is pretty restrictive.
    Fast handovers for Mobile IPv6 over 802.11
    Pete McCann - 
    802.11 needs to handle FMIPv6 situations.
      Implementing exotic device drivers ?
    Is the signal-to-noise ratio information truly real-time or is it just 
    updated every n sec ? 
    802.11 trigers:
      -contains old AP and new AP MaC address
      - enables  IAPP operation
    Anticipation is difficult. firmware/driver makes autonomous
    real-time handover decisions.
    Hesham: firmware makes this decision based on SNR?
    Pete: yes. proprietary mechanisms.
    But not impossible. HostAP or SoftWiFi model supports this.
    Exotic device drivers support this. Not possible with all cards.
    James: no way around to scan. scanning is costly. you can put in adhoc 
    mode, this can be a solution.
    Pete: you can rewrite the scan mechanisms.
    Bernard Aboba: no specifications in this field. behavior is variable.
    But this is not necessarily a problem. 
    Gopal:  some nics allow you to associate with to APs.
    Pete: this is againist the spec.
    Bernard: you'd have two macs, and learning switches will take care of it.
    Rajeev: motivation is not to disallow this feature where it's 
    People claim they are doing this in the experiments.
    James: we couldn't do it.
    Bernard: some nics don't use SNR. 
    James: we cannot fix this here.
    Hesham: exactly. if your nic can do that, use fmip, if not, bad luck.
           WEP ?
           802.1X? (secure but not fast enough across subnets) PANA? (Not 
    ready yet) Both 802.1x and PANA require anticipation.
    Bernard: pre-auth allows anticipation and reassociation does not always 
    imply final decision. 
    Next Step:
     It was recommended that more work is needed at IEEE for 802.11 to 
    support MobileIP.
     Pete asked if this work should be a working group item. Fast handoff 
    draft needs some updating to reflect 802.11 fast handoff.
    - is anticipation realistic?
    James: if no anticipation, no benefit.
    Hesham: informing people about what information needs to be passed up.
    Rajeev: distance of CN is also essential.
    Bernard: IEEE is like IETF. if you are willing to go there, perhaps you can 
    get some of thes things. things inside the host is not as 
    - relationship of PrRtSol to CARD? Open issue
    - Fate of this draft? - To be discussed further on list
    FMIPv6 Update
    Rajeev Koodli - 
    tunnel can be established by
    - prrtadv
    - L2 indication
    - FBU
    Forwarding on the tunnel started by FBU.
    From mailing list discussions:
    - move prrtsol/prrtadv to and earlier time
    - allow prrtsol to include a wildcard, dowload info for all 
    neighboring AP-AR.
    Hesham:  we have a security problem. we need to solve that.
    James: concerned about CoA configuration.
    James: Concerned about FBU assumptions. With my IAB hat, I'm concerned 
    about the architecture here. Two types of mobility here. 
    Alternatives to FBU along the line of ND, ICMP redirect need to be 
    Design Team status on MIP traversal across IPsec VPN gateways
    Gopal Dommety
    - define problem statement (finished)
    - get WG blessings on the problem statement (to be done)
    - work on high level solution with IPv4 focus (to be done)
     seamless IP mobility across VPN. (VPNs for remote access, or 
    encrypting traffic. )
    - HA inside the enterprise, inside the VPN domain.
    - MN inside the VPN domain, HA on the Internet. (only problem when the MN 
    inside the VPN domain).
    Solution guidelines:
    - none or minimal IPsec changes
    - no changes to vpn/dmz architecture
    - minimize software upgrades
    solution options:
    - using dual mobile IP layering. one inside, one outside the DMZ.
    - use of proxy entity which is mip aware
    - making vpn concentrator accept outer IP address changes without 
    breaking IP security.
    - use IPsec tunnel instead of GRE/IPinIP tunnel.
    RFC3012bis Issues
    Jayshree Bharatia - 
    Jayashree discussed the issues and proposed clarification text for 
    rfc3012bis in response to AD comments and mailing list discussions.
    The details are available in the slide presentation. There was no 
    objection on the changes proposed.
    HMIPv6 Update
    Hesham Soliman - 
    - removed extended mode.
    - updated BU format based on the base spec.
    - MN allowed to perform RR to CNs.
    - described how the MN establishes an SA with MAP in detail.
    removed chapter 9: single message including two BUs.
    specify timeouts and local retransmissions of local BUs.
    need for another MAP discovery mechanism.
    Question to the group:
    current scheme assumes that there is no need for testing the CoA in order to 
    authorize the local BU. MAP is similar to HA.  Is this assumption 
    IPR only applies to Dynamic MAP discovery.
    Erik: if LCoA is not limited, then attacker can launch an attack on 
    victims outside. 
    Hesham: We discussed this, but We don't have it in the draft. Three way 
    handshake is an option.
    Samita Chakrabarti
    registration deadline: feb 7, 2003
    will focus on mobile IPv6 testing.
    no mipv4 conformance testing, only interop on mipv4.
    Proposal: How about mipv6 interop test bed on 6bone? for continuous 
    Charter Revision
    Gabriel Montenegro outlined the charter revision proposal. The charter has 
    been discussed between the chairs and the ADs and the outcome is as 
    current charter/milestones outdated.
    There is a desire for better focus.
    different maturity levels, mipv4 vs. mipv6.
    different goals: mipv4: deployment. mipv6: finishing basic 
    functionality (and optimizations).
    (mostly) different constituencies.
    Current WG has a split personality.
    Split into 2 WGs:
    - mipdep WG: mobile IP deployment WG.
    not mipv4 specific., focus on mipv4, but mipv6 also ok.
    operator issues.
    other SDO's requirements for deployment.
    - mipv6 WG
    hopefully short lived WG.
    narrower charter, better focus.
    mai extensions
    registration revocation
    mipv6 wg:
    - mipv6 spec.
    - bootstraping
    - modularizing mipv6 spec into smaller specs
    - some optimziations
     - hmipv6
     - fmipv6
     - ND modifications
     - movement detection
     - simultaneous bindings
     - optimistic/fast DAD, router discovery.
    drafts will mostly be moved and adopted automatically.
    Charles: would new attempts to develop mipv4 related protocol be 
    discouraged if not related to deployment?
    Basavaraj: they are not prohibited.
    George T.: some deployment points to new protocols.
    Hesham: what was the justification?
    Gabriel: split personality. 
    Hesham: why hmipv6/fmipv6 are experimental? what is the criteria do 
    decide something is experimental.
    Basavaraj: determination should not be arbitrarily set. interest level, and 
    implementations are important.
    James: these technologies need to be tied into real-life 
    Gopal D.: agree with the split personality problem. it's better to split 
    mipv4 vs. mipv6.
    George T.: are we opening the flood gates? one meeting per IETF was 
    controlling it.
    Samita: split is good, but... mipv4 and mipv6 is a better idea.
    Phil Roberts: we'll be discussing this on the mailing list. no 
    timeframe yet.


    HMIPv6 Updates
    Mobile IPv6 - Base Status & Open Issues
    RFC 3012bis Issues
    Mobile IPv6 Fast Handovers: Update
    Fast Handovers for 802.11
    Connectathon 2003 -Interoperability Testing for MobileIP
    Mobile IP Traversal across IP Sec VPN Gateways
    Rechartering the MOBILEIP WG
    Mobile IP WG Doc Status