2.3.9 Mobility for IPv4 (mip4)

Last Modified: 2003-08-25

Gabriel Montenegro <gab@sun.com>
Basavaraj Patil <basavaraj.patil@nokia.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <mrw@windriver.com>
Internet Area Advisor:
Thomas Narten <narten@us.ibm.com>
Mailing Lists:
General Discussion: mip4@ietf.org
To Subscribe: mip4-request@ietf.org
In Body: subscribe
Archive: www.ietf.org/mail-archive/working-groups/mip4/current/maillist.html
Description of Working Group:
IP mobility support for IPv4 nodes (hosts and routers) is specified in
RFC3344. RFC 3344 mobility allows a node to continue using its
'permanent' home address as it moves around the internet. The Mobile IP
protocols support transparency above the IP layer, including maintenance
of active TCP connections and UDP port bindings. Besides the basic
Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns
such as optimization, security, extensions, AAA support, and deployment

Mobile IPv4 is currently being deployed on a wide basis (e.g., in
cdma2000 networks). The scope of the deployment is on a fairly large
scale and accordingly, the MIP4 WG will focus on deployment issues and
on addressing known deficiencies and shortcomings in the protocol that
have come up as a result of deployment experience. Specifically, the
working group will complete the work items to facilitate interactions
with AAA environments, interactions with enterprise environments when
Mobile IPv4 is used therein, and updating existing protocol
specifications in accordance with deployment needs and advancing those
protocols that are on the standards track.

Work expected to be done by the MIP4 WG as proposed by this charter is
as follows:

1. MIPv4 has been a proposed standard for several years. It has been
  adopted by other standard development organizations and has been
  deployed commercially. One of the next steps for the WG is to advance
  the protocol to draft standard status. As part of advancing base
  Mobile IP specs to DS, the Mobile IPv4 NAI RFC (2794) will also be
  progressed towards DS.

2. Key exchange using AAA infrastructures for setting up security
  associations defined in RFC3344 will be completed.

3. The AAA WG, which is currently dealing with the Diameter Mobile IP
  application, requires the AAA NAI for Mobile IPv4. This work will
  be completed by the WG. The MIP4 WG will also work with the AAA WG
  to ensure that the Diameter Mobile IP application is aligned with
  WG requirements.

4. Home agent assignment at the time of mobile-ip registration, rather
  than preconfigured for the mobile node, has been proposed in
  draft-kulkarni-mobileip-dynamic-assignment-01.txt. The WG will
  take on the task of completing this. The ability to switch the home
  agent assigned to a mobile node while registered will also be
  considered as part of this task.

5. Work items that are pending from the previous Mobile IP WG, which
  will be completed by the MIP4 WG, are RFC3012bis (Challenge-response
  mechanism),low-latency handover draft to experimental status and the
  completion of the MIB for the revised base Mobile IP specification

6. The MIP4 WG will also complete the work on Mobile IPv4 interactions
  in VPN scenarios. This work will involve identifying the requirements
  and a solution development for Mobile IPv4 operation in the presence
  of IPsec VPN's.

Other potential work items may be identified in the future but will
require an appropriate recharter.
Goals and Milestones:
Jun 03  Registration Revocation completed
Jun 03  AAA Keys for MIPv4 completed
Jun 03  AAA NAI for MIPv4 completed
Jul 03  Revised MIPv4 Challenge/Response (3012bis) completed
Jul 03  Complete MIPv4 VPN interaction problem statement
Aug 03  FMIPv4 to experimental
Sep 03  Advance NAI specification to Draft Standard
Oct 03  Revised MIB for MIPv4 completed
Nov 03  Complete alternate HA-MN security configuration mechanisms
Dec 03  Advance MIPv4 specification to Draft Standard
Feb 04  Dynamic Home Agent assignment
Feb 04  MIPv4 VPN Solution to IESG
No Current Internet-Drafts
No Request For Comments

Current Meeting Report

Mobility for IPv4 BOF (mip4)

Monday, July 14 at 0900-1130


CHAIRS: Basavaraj Patil <Basavaraj.Patil@nokia.com> Gabriel 
Montenegro <gab@sun.com>  Phil Roberts 

NOTE: MIP4 is in the process of being approved as a working group.

Final approval MAY happen before Vienna IETF. Details,

work items, chairs, etc are likely to change.

All presentations slides are available at the following web site.


San Fran: discussion on next steps in IP Mobility

Proposal of 3 BOFs: MIP4, MIP6, MIPSHOP

AGENDA bashing

Discussion on Charter and potential work items: 15 min

Presenter: Chairs

Charter Highlights

Interoperability of existing implementations

 Look at proprietary extensions

Progressing the MIPv4 base spec to draft standard

Completion of AAA Key exchange for MIP

AAA-NAI completion and MIPv4-AAA review

Dynamic HA assignment discussion

VPN Solution for MIPv4 completion

Samita: LPAS document? Should we publish as an informational document?

KLeung: some draft

Gopal: MIP depends on auth from the client. In WLAN, there is a lot of 
auth, fast auth, etc. Would it be something that the WG would consider to 
take advantage of this to do mobility?

Raj: if you could frame the question as something the WG could discuss, 
maybe... but, we are trying to limit the scope of the charter.

Gopal: not fast handoff, but it is a fundamental change in the way you look 
at mobility. Maybe you don't have MIP client on your laptop.

Gabriel: 2 things: one is to have L2 triggers with 

other thing: how to implement mobility on nodes that don't implement 

Gopal: so how do you take charge of a L2 trigger, second is how do you use 
some information to detect that MN has moved independent of MIP stack

ThomasNarten: might be related to BOF on dna later in the week. What does it 
have to do with this WG here? This is Mobile IPv4 specific things.

Gopal: biggest deployment problem is Mobile IP client stack. We can 
enhance existing framework to handle nodes without MIP stack.

KLeung: applies well to interoperability issue. Key thing is adding 
support for non-MIP clients using MIP infrastructure.

Thomas: That's interesting, but it's a big change. Not clear that this 
group should be the ones looking at it.

Kleung: people are doing this already, sometimes proprietary 

Gabriel: everything so far has been mobile initated. Not sure there's 
scope for network initiated.

Gopal: it is a mobile initiated, just not MIPv4 initiated.

Raj: the reason you would like to do this is because of the 
difficulty of deploying MIPv4 on you laptop, right?

Gopal: there is work going on elsewhere.

Raj: trying to figure out what is the proprietary 
implementations of MIPv4, see if there is enough interest in this 
working group to standardize some of these

ErikN: when you do this, you have to change home agents too, right?

Gopal: there are ways not to change any HA code at all and still make it 
work. Or, there are ways to make it work better.

RajeshKumar: have worked on IPSec agent implementation. As far as MIPv4 
clients are concerned, haven't seen any incompatibilities There are a lot of 
L2 switches that a number of vendors are trying to build. This is 
mobility at L2, they are not using network layer.  No issue with 
compatibility of Mobile IP.

Gopal: LAN switches & VLAN switches: sometimes layer 2, but sometimes 
layer 3

RajeshKumar: no, L2 is L2, if you do L3 you need MIP.

ErikNordmark: dynamic HA issue: might want to configure more things when you 
connect to your home ISP. enroll BOF, Is there synergy between these 

Gab: that point will be explored a bit more in the MIP6 BOF. Heard about 
enroll, doesn't seem to help that much for handoff from one HA to 
another, but might help with the initial case.

Raj: other thoughts on the charter?

Eric (FranceTelecom): Working documents, low latency handoffs?

Raj: completed by WG, consensus make it experimental. WG would no longer 
work on it. We just have a milestone to get it to the IESG & publish it.

VPN Design Team Update: 20 min

Presenter: Gopal Dommety

Problem Statement Draft

DT version is finished

Security review by Radio Perlman

Draft is published


 The I-D which will be completing WG LC before the meeting has been 
revised following reviews by the Mobile IP security advisor (Radia 
Perlman). The intent is to provide a status update on the problem 
statement as well as discuss any LC comments/issues that may be 


 Base Solution (no IPSec changes)

 Optimizations (some changes for efficiency)

Base Solution - work completed

Need security review

Last Call for base solution after security review and Problem 
Statement review

by WG and IESG

Optimizations to be completed before next IETF

Problem Statement details

16 page draft

IP Sec VPN is used to access the Enterprise network

How do you get seamless mobility when moving from one hotspot to another or 
to wide area provider

Mobility from one subnet to another inside enterprise

Transition from inside enterprise to outside and back

Figured out all the various placements of IPSec, Home agents, 
firewalls, foreign agents.

The one that made most sense is:

 HA deep inside enterprise network

 VPN at the access concentrator

Issues and requirements

 Without FA: the IPSec SA needs to be renegotiated on movement

 With FA: FA cannot modify/process IPSec packets from the MN

Problem statement draft includes:

 Issues that need to be addressed for providing seamless mobility in this 
scenario Requirements for the solution

Working Group Last Call

RajeshKumar Requirements document is pretty complete Solution draft 
covers detail (42 pages) but to go to last call people will need some time to 
review all solutions

Gab: only problem statement is about to go to last call.

 One comment: "seamless" here might be inappropriate

Gopal: a little marketing on my part, will look into it

VPN solutions discussion: 20 min


Presenter: Sami Vaarala of Netseal

 The design team has discussed a number of options in the solution space. 
This agenda item is aimed at presenting the conclusions reached and the 
reasoning behind the choice being made.

VPN solutions draft

Conclusions and rationale

 Document a base approach with minimal changes to standards

 Optimizations considered (but postponed)

 We need a home agent inside the enterprise

 We need an external mobility agent

 IPSec does not have standardize mobility (SA endpoint update)and we want 
"seamless" mobility even when outside We need to support FAs in the 
external networks => the lowest layer must speak MIP Some problems left out 
of scope for now e.g., network with only HTTP access

Three layer solution


External home agent + firewall + internal home agent

First step: discovering whether inside or outside.

Send RRQ to external and internal HA, get response from only internal HA.

When MN is outside

Send RRQ to both external and internal HA, get response only from 
external HA

Then run IKE, VPN address assignment

Then run RRQ inside tunnel to internal HA.

Must use reverse tunneling to internal HA

External movement is handled just by external HA/Mobile IP

Pros and Cons of 3 layer solution


 Only MN is aware

 No changes to IPSec of MIPv4


 Overhead (latency, packet size)

 Three layers to manage (e.g., authentication)

 Software complexity

Three layers != three boxes

 Combined VPN + HA box possible


 -02 missing some comments; pending security review

George Tsirtsis: do the HA's need to be close to the firewall?

Sami: no

Charlie What you are assuming, is that it is difficult to make the 
internal HA visible to the firewall. Typically, firewalls do permit 
visibility to an internal host.

Sami yes, but we are assuming that we have to go through IPSec gateway

Charlie why? Maybe packets to HA would not need to be IPSec 
protected, nothing prevents you from using IPSec to the HA This 
solution goes beyond complex to fantastically complex

Sami: if each HA were part of the security perimeter, our solution would be 
simpler, but very hard to achieve in practice. but yes we would like to 
work on optimizations.

Henrik: using IPSec directly to the HA is one way, but is not 
acceptable to

many network administrators. We don't have to work on it in any case 

it's already supported by standards. If we have to pick one, this is it.

Kleung: this is one reason we need a deployment WG. 

RajeshKumar: Generally, VPN manufacturers are a bit different from 
mobility vendors It's very hard to get someones IPSec client to work with 
someone else's software. Given that, don't foresee that some vendor will be 
able to deal with all different IPSec implementations. So 
implementation of firewall will be separate from HA for some time.

Gopal: complexity is a very relative term. This is a pretty simple 

Gabriel: any implementation experience?

Sami: yes, some, it's doable with client in Windows. It's not too easy but 
it's possible. It has been used in practice already.

Henrik: Birdstep has one commercially available, we have one 
internally available

Gabriel: seems like this would have a certain overhead even if you are 
internal, right? You have to wait for both registrations to detect where you 
are, and there are some retry issues.

Sami: yes, but strategy is that if you get a response back from the 
internal HA, you just forget about external HA. If external one 
responds first, you can accept it optimistically, or retry a few times.

Gabriel: you can maybe use some L2 information

Sami: yes, you might keep a table of MAC addresses but need to keep in mind 

Charlie: intended to be a solution to work without changing 
administrative practice As it's presented, it seems to say that this 
complicated solution is the base solution, and benefit is that you don't 
have to change anything. I would request to present this solution as a 
trade-off. One is to admit packets to go back to the HA. HA is supposed to 
deal with security. It is reasonable to suggest to a firewall 
administrator that they allow packets to go to HA unprotected.

Thomas: charlie's point is a pretty good one, you should have an 
applicability statement. If you are willing to punch holes in the 
firewall, maybe you can have a slightly more efficient solution.

[more discussion back and forth between gopal & charlie & thomas...]

Sami: we will clarify for next draft.

Dynamic HA discussion: 20 min


Presenter: Kent Leung

Capability already deployed in some wireless operators

Optimal Home Agent for geographically/topologically distant locations

Reduce configuration needs on Mobile Nodes (HA pre-assignment not 

Allow network to select and administratively assign HA to MN

Load balance MNs among multiple HAs

Hope to accomplish before next IETF

Finalize WG charter and chairs

Settled by 4 weeks from the end of the meeting

Short WGLC on Low Latency handoff in July

 To IESG in August

Progress AAA keys and NAI

 Interactions with AAA WG

RFC 3012bis to IESG in August

MIPv4 problem statement to IESG

pete: security quesiton is the most important one, yes. but this problem of 
configuring a SA across domains is very hard. in pp2 we don't have it yet 
cuz we're waiting for aaa keys and aaa-mipv4 

henrik: why both all 0's and all 1's, why not choose 1?

pete: diam mipv4 applic did make a difference we don't, we only allow 
assignemtn in the home domain, but eventually we want to have it also 
request in the foreign domain

panasonic: would like to see more security discussion

kent: yes, but we don't want to get tied down to only one method

charlie: why not use the initial HA makes the encoding instead of the AAA 
(analogous to AAA keys). so do you insist on leaving it open?

kent: yes

charlie: but for example, which SPI to use? there's a roadmap with the AAA 
drafts, why not use it?

kent: not diff from 3344

charlie: yes different, additional parameters to store and transport, in 
3344 each HA-MN requires a different MSA

??: route optimization to solve this?

kent: you need one ha already. here you don't need to have anythijng 

raj: the point is if you wish to keep the ha closer

pete: this draft should not go forward without a security solution. it 
really should be part of the same roadmap as aaa keys and aaa-mipv4. and not 
comfortable with sharing one MSA for a group of HA's

kent: aaa is not the only way to do it

pete: but it should have at least one way of doing it

raj: pick a specific method, perhaps the aaa-mipv4 application,

but there's need for a solution cuz the current rfc3344 won't quite work



thomas: finalize WG and chairs within 4 weeks

Narten: Status of AAA keys?

Tom: most comments addressed, but Lifetime field not used.

Charlie: sporadic mention of route optimization for MIPv4, but charter 
seems to be crafted to exclude it. Under what circumstances would it 
become a work item?

Raj: haven't necessarily seen as much interest. Need to generate 
interest on mailing list.

Gabriel: we were looking at aggressively reducing the number of items.

Narten: we should focus on issues where theres deployment 
experience/issues. Working group needs to come up with criteria for when 
there is real interest. Real interoperability problems for 

Kent Leung: (maybe controversial, but) could we consider 
Experimental message types similar to VSAs, but act as feedback to 

Raj: similar to VSAs that we already have

KL: not an extension, but a message type

Narten: there are some numbers to use for 
experimentation/testing, if obstacles we can talk about it.

Raj: other items, 3012 bis

Gab: reminder that Wednesday morning is MIP6/MIPSHOP

IRTF BOF: registration desk 10pm tonight

Dave Johnson: Mobicom 2003, Sep 14-19, San Diego



Roadmap for MIP4
MIP4 BoF at IETF57
MIP4 BoF Charter
Mobile IP VPN Design Team Update
Mobile IPv4 Dynamic Home Agent Assignment Framework