2.5.2 IP Routing for Wireless/Mobile Hosts (mobileip)

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

Chair(s):

Phil Roberts <qa3445@email.mot.com>
Basavaraj Patil <basavaraj.patil@nokia.com>

Routing Area Director(s):

David Oran <oran@cisco.com>
Rob Coltun <rcoltun@redback.com>

Routing Area Advisor:

David Oran <oran@cisco.com>

Mailing Lists:

General Discussion:mobile-ip@standards.nortelnetworks.com
To Subscribe: listserv@standards.nortelnetworks.com
In Body: (un)subscribe mobile-ip first_name last_name
Archive: http://www.nortelnetworks.com/standards

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.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

RFC2002

PS

IP Mobility Support

RFC2006

PS

The Definitions of Managed Objects for IP Mobility Support using SMIv2

RFC2005

PS

Applicability Statement for IP Mobility Support

RFC2004

PS

Minimal Encapsulation within IP

RFC2003

PS

IP Encapsulation within IP

RFC2344

PS

Reverse Tunneling for Mobile IP

RFC2356

 

Sun's SKIP Firewall Traversal for Mobile IP

RFC2794

PS

Mobile IP Network Access Identifier Extension for IPv4

RFC2977

 

Mobile IP Authentication, Authorization, and Accounting Requirements

Current Meeting Report

Mobile IP WG at IETF49 meeting minutes. Thanks to James Kempf and
Scott Corson for capturing the proceedings.

--------------------------------------------------------

Session 1:
::::::::::

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
vendor extensions

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.

Connectathon Event

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.

Proactive FAs

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.

Comparisons:

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.

Scenarios:

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.

Network initiated.

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

Some variations.

Plans.

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.

2 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

MAP discovery:

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

Implementaiton.

INRIA has a KAME and FDupont implement.
300 lines

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.

--------------------------------------------------------

Session 2:
::::::::::

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

----------------------------------------------------------------------------

Slides

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)