NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 18-Oct-00
Phil Roberts <firstname.lastname@example.org>
Basavaraj Patil <email@example.com>
Routing Area Director(s):
David Oran <firstname.lastname@example.org>
Rob Coltun <email@example.com>
Routing Area Advisor:
David Oran <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: (un)subscribe mobile-ip first_name last_name
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:
Review and approve the charter, making any changes deemed necessary.
Post an Internet-Draft documenting the Mobile Hosts protocol.
Review the charter of the Mobile IP Working Group for additional work required to facilitate non-host mobility.
Submit the IPv4 Mobile Host Protocol to the IESG as a Proposed Standard.
Submit the IPv6 Mobile Host Protocol to the IESG as a Proposed Standard.
Submit Internet-Draft for NAI support in Mobile IP to IESG for consideration as a Proposed Standard.
Review security framework requirements for Mobile IP.
Review solutions and submit drafts for mobility in private address spaces.
Supply AAA requirements for Mobile IP to the AAA Working Group
Submit the IPv4 Mobile IP Protocol to the IESG for consideration as a Draft Standard.
Review the WG charter and update as needed.
Develop an access technology independent method for supporting low latency handover between access points within an administrative domain or across administrative domains.
Review QoS in a Mobile IP enabled network.
Submit Mobile IPv6 MIB to IESG for consideration as a Proposed Standard.
Request For Comments:
IP Mobility Support
The Definitions of Managed Objects for IP Mobility Support using SMIv2
Applicability Statement for IP Mobility Support
Minimal Encapsulation within IP
IP Encapsulation within IP
Reverse Tunneling for Mobile IP
Sun's SKIP Firewall Traversal for Mobile IP
Mobile IP Network Access Identifier Extension for IPv4
Mobile IP Authentication, Authorization, and Accounting Requirements
Mobile IP WG at IETF49 meeting minutes. Thanks to James Kempf and
Scott Corson for capturing the proceedings.
Agenda bashing - accepted. Other topics deferred to end of session 2.
Charter update - streamlined, specific to MIP, other stuff offloaded to Seamoby.
- fast handoff for mobile IP v4 & 6
FH MIPv4 - complete
FH MIPv6 - in progress
MIPv6 spec - issues pending
New RFCs - Info 2977 AAA Reqs.
3012 MIPv4 CHAP, Standards track.
Editors queue - 2344bis - reverse tunnelling
Passed WG last call - route optimization (no comments)
move to IESG next week
regional tunnelling (issues raised)
being addressed, revision forthcoming
Possibly another wg last call.
general NAI ext. (no comments)
to IESG next week
MIPv6. Security issues, new revision
result of changes. IPSEC WG
Other IDS - 2002bis IESG last call complete
Ext rationalization - fallen off. Complete last calls last time, (AD comment?)
3G wireless extensions - WG last call, issues during IESG last call discussion, returned to IESG.
HMIPv6 - going to WG doc. Talk about today. Original and INRIA proposal, concensus, no comment.
Testing of MIPv4, MIPv6, Diameter.
Questions about including HMIPPv6 since it is not yet official.
Dave Johnson - Mobicomm announcement (Rome)
Charlie on MIPv6 update.
reduce confusion, clarify, make sure interoperable.
text included, placements for home address option and binding update option.
Home address option - needs to be in front of security headers but before routing header, but means that intermediate nodes must process.
IPv6 - dest options before routing and after security, but can put elsewhere. Will be after routing header but before fragement header (like to have firewalls use home address for processing).
Binding update after security headers. Renumbering work, appendix on how to get home address if you don't have one to start with. Main part of draft, spec on what to do when home network renumbers, want to avoid flooding router adverts.
Q. does this use ESP? Later.
Eliminate renumbering, part of message flow.
How to calculate AH (needing for binding update auth)? Home address option changes care of address, calculate on stream of data w. home addr in IP addr field and coa in home addr optoin. Security association is considered tied to home address.
Use of ESP or AH? Draft allows AH only now. Revisit requests - return to this.
Can send router solicitation to get more lifetime for home address, request from home agent.
D bit - does HA have to do duplicate addr detetion? HA may or may not make sure unique. If mobile does out of blue, dup addr detection necessary. Takes longer than spec was for retransmitting BU. Initial BU retransmission longer.
Details about home agent delaying router adverts when home network renumbered.
minor point - preferences for HF must be zero if unspecified.
Issues during last call:
use ESP? - AH put into IPSEC without full enthusiasm from IPSEC, seems right for binding update. AH is mandated for use with BU and BA. If ESP is better, then why not allow? Reason for doing w. AH: it works.
Politial problem in IPSEC - some IPSEC WG members want to get rid of AH.
Meeting with security people, no agreement on AH v.s. ESP. Will be sent to ADs.
Question: do they need to redo IKE associations if using ESP and go mobile? Hardware acceleration is easier for ESP.
Changing opposition: advanced stage of last call. Using ESP in tunnel mode? No overhead.
Tech problem: must auth binding update, doesn't contain HA or CoA. ESP only protects part below header, AH protects whole packet. CoA is above ESP, so would not be protected. Overhead of adding CoA lower down is too much, too many ways to encode.
ESP is slightly larger than AH, but to add CoA lower down would require 16 bytes for address, 2 bytes for identification, another 6 bytes for padding.
2 kinds of overhead, per packet, overhead of additional SA, need to be discusssed. SA overhead only once, when you go mobile.
Process issue: consistent doc not there, will get comments from IESG. Last night: send to AD with preface pointing to issues. Trying to complete. IETF last call once.
Code running is for draft 13.
But not in draft. Only two implementors know how to do it. Code is not in draft.
Nonagreement - whether it should be specified in draft.
What's in the draft- result of last interop test.
What is the prob getting doc only using AH, details yet to be resolved. Separate draft about how to use ESP.
With more implementation experience, then revise.
ESP has momentum.
ETSI bakeoff, didn't have AH, one implementation does not use AH. BA, protected by AH, can't protect unless in tunnel mode because can't protect routing header. Using AH makes simple to protect routing header.
AH v.s ESP discussion ended.
How does key negotiantion between CH and MN occur.
SA is associated wi. HA not CoA.
Security DB selectors is difficult problem, select from database for doing auth, not this level of granularity in IKE. binding update one SA, ack another.
How does BU security scale? Security ADs lead that it is broken. But logic says that IPv6 security is therefore broken.
Operational issue. Not a routing area issue. Solution: do triangle routing.
Intractable problem: global PKI, narrow slices. What is MIP issue is how many SAs need to be created.
Many keys, could have an SA that does both BU and normal traffic.
FH design team - reduce number proposals to one
two proposals, combined three into one of two
email to only use messages from binding family
authors felt that needs bidirectional support.
need both oFA and nFA to initialte.
Source and target triggers.
Source: oFA sends msg to nFA,
Target: nFA sends msg to oFA.
Bicasting - once handoff message, new packets sent across both, no L2 - drop packets.
Address power consumption - dormant mode, don't require mobile to awake. Draft doesn't require.
generalized link layer address - include hardware address to map link layer to mobile.
Also supports regional registration. mobile moves to new FA, message handoffs occur, nFA knows a GFA involved, regional reg done by GFA.
Was design team to come up with solution or combine drafts?
v4 - consolidate drafts where possible, one draft going forward. Not all possible scenarios.
v6 - more comprehensive.
Result not to rubber stamp.
Security to prevent hijacking of messages, why transfer?
Assume trust relationship.
FAs have security association, includes FA/FA auth extension, can prove.
Only proves who I am, not that it's authed.
Some access networks in which assumption is not valid. Possible to solve fast handoff with 802.11?
Hasn't looked at those access networks. IAPP only in one subnet.
How to you handle packet loss? Is L2 authenticated?
Hesham: mobile does movement detection.
uses standard 2002.
support both mobile network, mobile most be able to decide whether it can register or not.
support ping-pong. No knowledge of timing.
independent of L2.
support local mobility, with GFA, etc.
Anticipate if L2 allows you to do so.
Simultaneous binding, S bit to two locations to support ping pong.
Relay to mobile node, mobile node runs movement detection, registers right away w. SA2, mobile node moves to FA2, traffic is already there. Not necessarily two streams because L2 may drop. Need to decouple from L2. Don't have to base on regional.
Final particular case, GFA as first hop, bicasting to to both places, but sent to where out.
FH draft requires L2 messaging over the air before complete.
Need to have an advert multihop solicatation, mobile node must come on traffic channel, no access to signalling channel, send reg request, reply back before handoff can take place, indicate to network that complete.
Radio environment may deteriorate during handoff on old link.
Provisioning neighbors. Associate link layer triggers w. FA both, FH also requires advert
FH relies on GFA to redirect traffic.
Who is in control? FH mobile has control, L2 controls today, mobile has final say.
Karim. Mobile can do movement detection.
One approach, do registration after, not clear. Don't need to adverise.
Intersystem handoff, no new messages in FH.
Forced by network to do handoff where you don't want to go, network hands you off, data sent to wrong FA, no sim bindings, clear problem.
Much discussion about L3 v.s. L2 handoff.
L3 signalling appropriate for multiple L3 handover, shouldn't rule out L3 smarts.
Bicasting, base stations can't tell if mobile is dormant or talking to another base station.
Discard rather than buffer on L2.
Put drafts together, assumptions on link layer, similar kinds of network.
Several types of scenarios. Can you start with something and cover all cases?
Come up with a generic solution? Not for one link layer.
IAPP traffic for monitoring on 802.11.
What is the best handoff?
Merge two drafts?
Hum says merge.
IPv6 fast handoff.
Design goals - be flexible, one size does not fit all.
Focus on Break before Make - most clear cut case.
Mobile initiated/network initiated.
L2 features when available, but also when not there
Robust, fall back.
Other MIP features - bicasting, buffering, context transfer, localized mm
Advance prepartion of the handoff.
Use MIPv6 messages where possible.
1) Mobile nod initates handoff at new access router
2) New access router initiates handoff when mobile connects... 2 others
initiate handoff at old, prepare hanoff btween ARs, complete handoff at new details not done.
Data coming to old AR, trigger, tells you that handoff needs to take place.
Proxy Router advert send to MN, allows mobile to create new CoA before gets to new AR, mobile may need to send a BU.
Old AR sends handoff iniitate to new, acked by new
Mobile connects to new, handoff update, new starts forwarding to mobile.
Later mobile sends BU to home agent, etc.
Will mobile get a binding ack? Could come on old link or new, if old is deteriorated.
Mobile requests special router solicitation for new one. after that, same as previous.
Layer 2 assist.
Layer 2 trigger at old causes binding update to new AR.
HAck returned. CoA is actually old CoA, mobile can't create new CoA, old is valid at new AR for awhile, gets new.
High level done, devil is in details.
New draft with solution section to be published by end of year
Regular drafts published as details get resolved.
Conference calls, face to face in January.
Finsh by Minneapolis.
Include more scenarios?
Merge of INRIA and HMIP
motivation: reduce MIP signalling, reduce signalling delay
one or more anchor points in hierarchy
LCOA on link, MAP CoA
MN binds LCOA w. MAP,
Packets intercepted by MAP nd encapsulated to MN.
HMIPv6 does not require new security assoc modify MIPv6
no new protocols
no special routers
prevent a mn from using both modes.
1) basic, one MAP-COA per MN
2) MAP-COA belongs to the MAP subnet
3) Map intercepts packets to MN's COA
extended: MAP0COA is the MAP address
Map receives packets and forwards to LCOA
Less encapsulation overhead when RO is used
MAP is slightly different from a HA
Ch7 has a comparison why might need either
Dynaimc map discovery (should be secured)
Router renumbering extension
map optoin in a destiantion option sent to the ARs (from the MAP or another node).
INRIA has a KAME and FDupont implement.
Two implementations interop test in Connectathon.
Need an IPR statement at end.
can mobile node use MAP on link, eq. foreign agent.
Modifying router adverts? Adding an option.
No new protocol? Modifying MIP protocol, didn't modify binding update.
Only supports one layer of hierarchy.
More than one layer of hierarchy, will select more than one MAP, mobile needs to know which MAP to send to.
MAP sends packets to mobile node, encapsulate.
Restictions on MAP location in topology? HA only works because is on same link, MAP sends option with prefix, home agent may not need. Not subnet that mobile is visiting, necessarily.
Two BUs to MAP and to HA. What about only one?
Why not just fast handoff? Doesn't reduce amount of signalling. Would need to update BUs to all CNs.
Map needs to know LCOA.
difference w. fast handoff - design team's fast handoff, update previous access router, could also be elsewhere.
No provision for MAP to MAP, standard MIPv6 smooth handoff.
Flexibility of not having FA on first hop, not forced to have hop by hop hierarchy.
v4 allos coloc coa. most usual case on subnet.
A Framework for QoS Support in Mobile IPv6, Hemant Chaskar, Nokia
MIPv6 does not yet address QoS. This is a proposal to perform QoS signalling in MIP by introducing a QoS object as an IPv6 extension header, where the object corresponds to one unidirectional packet stream. Object should describe required packet volume, and is included as a hop-by-hop option. Different approaches to handling MPLS, DiffServ and IntServ are included. Comments from floor that this is (or will be) reinvention of RSVP. Object would be sent end to end in BU from MN to HA and CN.
IPv6 Regional Registrations, Charlie Perkins, Nokia
Mentioned solutions to RR problems discussed in Pittsburgh. The idea is to reduce signaling to the HA and CNs. The new approach uses an anycast group as the destination of a BU. This was challenged as not being defined in IPsec. The approach uses hierarchical anycast to localize signalling, and can be viewed as a distributed, more robust structure. But unfortunately this approach nails down the data path (like loose source routing) due to security requirement of BUs, and thus does not have the robust properties that it might have otherwise.
Mobile IPv6 ETSI Bakeoff, Vijay Devarapalli, Nokia
Report was given on what occurred.
Mobile Network Support in IPv6, INRIA, Thierry Ernst
Presented an approach for supporting mobile sub-network(s). Mentioned that with MIPv6 there is no way to send a packet to a mobile on a mobile sub-network. One solution is to send network scope binding updates. Sender of BU must be the mobile router, and must authenticate the BU as it manages the mobility of the subnet. The solution raises an issue of authorization, can the mobile router do this? Does HMIPv6 solve this and is it a better solution? It depends if MNs are mobile aware ...take to the mailing list.
Limited Private Address Support, Samita Chakrabarti, Sun
Private addresses are limited to mobile nodes only. Mobile must obtain a reverse tunnel with registration. A MN must have a unique home address in its home domain.
Paging Extension to Hierarchical Mobile IPv6, Regional Paging
MIP is bowing out of paging work for now according to chair in deference to ongoing work in SeaMoby. OUT OF SCOPE!
Registration Revocation in Mobile IP, Steven Glass, Sun
Original MIPv4 thought was that short lifetimes would be sufficient, and denial of service holes would be present otherwise. AAA has a requirement that a registration be revoked immediately. Termination messages must be authenticated. An easy solution? Perhaps not, as the revoke beacon can be spoofed. Pitfalls...comments from Dave J. are that the DoS hole should be closed. Pat mentioned that we should do this with MIP signalling and not ICMP signalling. Should the hole in 2002bis be documented in a separate draft?
DHCP in Mobile IP, Glass, Sun
Requires changes to HA only and not MN, FA or DHCP. MIP Extension proposed to carry full DHCP Ack. Using one home address to renew/get another requires turning the HA into a DHCP relay. Unclear as to whether/when this will become a WG draft.
Homeless MIPv6, Bengi Shalin, Ericsson
Bind sockets to dynamic address sets, not to single addresses. Update address sets via MIPv6 BUs. Home addresses are not needed, hence the name.
Home agents may still be used as points of contact, if wanted. Relies on DDNS, SIP etc. to be reachable (server-mode).
Intercepting Location Updates, Glenn Morrow, Nortel
Goals include simultaneous location privacy and route optimization. Allow a more realistic deployment of route optimization in IPv4. CoA hidden from CN by Network in new proposal. Brings the redirection function from the CNs to the last hop routers in the form of Correspondent Agents (CA). Makes use of Router Alert bit in IPv4. HMIP-type support is also possible.
A router can be configured to ignore a router alert or not, and this may be fast or slow path, or not. The required SAs between routers are typically already in place. 0-byte overhead tunnels (double NAT end to end) are also proposed. What happens if a wrong address occurs (memory error), there is no recovery option according to Dave Johnson based on past WG examination, and who claims the proposed approach has been previously discussed by the WG and rejected as not workable.
SGM Support in Mobile IP, Jiwoong Lee, Korea Telecom
SGM (implicit multicast) aims to help solve scalability of mobile IP multicast. Uses a level 3.5 header to enumerate the unicast destination address of all mobile nodes. IM packets can be sent from HA to FA COA or to MN CCOA. Assumes FA is not a mcast router. If native mcast is available, this is really not required as was pointed out by Alan.
Introducing Mobile IP in IPv4/IPv6 Interconnected Networks, Tsao, Siemens
Aims to solve problem of roaming between IPv4/IPv6 networks, homogeneous and heterogeneous cases. The basic approach suggests no new protocol, but requires translation which is generally to be avoided if possible. NGtrans is considering this issue as well, and George commented that NAT should be used as an option of last resort.
Diameter Extensions to MIP, Charlie Perkins, Nokia
Gave an update of changes to the draft, including allowing a home agent to be allocated in a foreign domain.
Mobile IP and GRE Enhancements, Pat Calhoun, Sun
GRE supports a key field used as a session ID and is multi-protocol. I-D defines two new MIP extensions, GRE key extension and the GRE type extension, to enable GRE protocol type pre-negotiation on registration prior to data exchange.
GSM SIM Authentication and Key Exchange for Mobile IP, Havinen, Nokia
Useful to bootstrap MIP/AAA infrastructure off of existing GSMSIM cellular infrastructure. See draft if interested.
SA Establishment for Route Optimization in MIPv6, Hesham, Ericsson
MIPv6 mandates secured BUs. This requires key exchange. What, how, when? IKE may be too heavy? Proposal is not as secure as IKE, not intended to replace IKE. Involves one RTT from MN to CN. Only works if CN has a AAA server. There is an IPR statement on this from Ericsson. Number of messages over the air is 4 or 6, but still less than IKE in aggressive mode.
MIP WG Wrap up from Phil
MIPv4 handoff consolidation will begin. MIPv6 handoff continues. blah...
Mobile IPv6 Revisions
Regional Registration for IPv6
SGM Support in MobileIP
Paging Extension to Heirarchical Mobile IPv6
Use of DHCP in Mobile IP
Registration Revocation in Mobile IP
Limited Private Address Support
Introducing Mobile IP in IPv4/IPv6 Interconnected networks
Homeless Mobile IPv6
IPv6 Bakeoff Hosted by ETSI
Mobile Networks Support in IPv6
A Framework for QoS Support in Mobile IPv6
SGM* Support in Mobile IP
Pro-active Foreign Agents
Mobile IP GRE Extensions
Interoperability Testing Event (Mobile IPv6, Mobile IPv4, DIAMETER)