Current Meeting Report
2.3.6 IP Routing for Wireless/Mobile Hosts (mobileip)
NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.
Last Modifield: 05/30/2002
Phil Roberts <firstname.lastname@example.org>
Basavaraj Patil <email@example.com>
Internet Area Director(s):
Thomas Narten <firstname.lastname@example.org>
Erik Nordmark <email@example.com>
Internet Area Advisor:
Thomas Narten <firstname.lastname@example.org>
General Discussion: email@example.com
To Subscribe: firstname.lastname@example.org
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
- 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
|Done|| ||Post an Internet-Draft documenting the Mobile Hosts
|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
|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
|JUL 01|| ||Review QoS in a Mobile IP enabled network. |
|AUG 01|| ||Submit Mobile IPv6 MIB to IESG for consideration as a
Proposed Standard. |
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
Mobile IP WG minutes (IETF54 @ Yokohama on July 15th, 2002)
Meeting minutes captured by Basavaraj Patil and Phil Roberts
Mr. Mastaka Ohta requested a presentation slot - rejected by the chairs, ADs asked, and then insisted that the ongoing persistent request be taken offline
3012bis has actually completed WG last call.
Actually, it has been sent to the IESG and is on the review list already.
3220bis is with the RFC editor and should be published as a new RFC soon.
Reg-Revocation in WG last call now.
AAA-Keys has completed WG last call and awaiting changes based on IESG review comments.
Resolutions of all issues will be proposed to the ML, with included text for the draft. WG will be able to comment.
76 - unclear response on whether to include this, asked whether useful, whether not. Dave Johnson requested whether it is dangerous to have it in the text and he and Charlie at least indicated some concern. Some found it useful.
74 - source selection, plus guidance here, plus implementors common sense will get this right (Hesham).
Dave J history - acknowledging that it is useful and is there so folks will know it is possible.
(Mr. Keichi?) some communications must use COA so text will be needed to clarify this.
(?) Problem needs to be solved, will be done elsewhere, not in this document.
(Francis) need something like API or state machines for some details and security descriptions.
(Hesham) in some other API, let's not make it CoA vs HA, but something more abstract.
62 - (Hesham) separate issue posted to the ML. Some twisted notion of ll home address and needing to keep what's at home.
(TJ) thinks it ought to be obvious.
(Francis) should wait for DAD and DIID before deciding on the best solution.
(Phil) let's go with what we've got
(Hesham) either defending home address or defending link local
(Phil) yes, home
72 - (Charlie) uses same binding update signalling as is in this draft, whereas the fast handover work has new signalling.
(James) there is signalling for this in the fmip draft.
(Charlie) Doesn't make sense to use the existing messages to do what it was designed to do?
(Rajeev) new signalling is slightly different.
(Charlie) even if you take it out, it could still be done. This provides guidance.
(Alper) maybe it would be best left where it is to allow better performance now.
(Erik) the security description is incomplete. (Note to self - work with Jari about what is actually needed to make this complete. If it's a lot, take seriously the request to drop it).
49 - (Hesham) need to clarify why this is a hard problem.
(Francis) this is a general IPSEC/IKE problem. Give it to IPSEC to solve.
(Erik) it is harder than what Hesham said: if I assign myself a temporary address (3041), preferred for a day, deferred for 6 days. Don't want anyone to claim it in the mobility case even though I used it for just a little bit. Hard - need something different. Not tied to binding lifetime, but the lifetime of the temporary address, conflict between multiple mobile nodes trying to claim the same temporary. Conclusion is agreeable to all.
56 - (FD) HA discovery is totally insecure and there is no way to make it sure.
(Hesham) It doesn't need to be secure. A fake HA will be discovered immediately.
(Raj) What is the threat with not securing the HA process?
(FD) Not sure, but need to use IPSEC and IPSEC will fail. All other proposed solutions can be done in a secure manner.
(Jim) Was arguing that maybe an alternative is possible, and reducing the size of the doc is a goal. Maybe there is an argument for a special protocol.
(Hesham) this mechanism serves a good purpose and it should be left in.
(Dave J) Removing features solely for the purpose of making the doc shorter is a recipe to further reducing the implemented functions.
(Jari) node requirements can mandate stuff
(Dave J) node requirements doesn't exist. At worst you create extra work rather than denial-of-service.
(Thomas) not clear there is a concrete proposal here. Need a concrete proposal if we're going to do something to replace this. Proposal is to keep it, finish discussion on the ML.
70 - (DJ) what is the purpose in making it mandatory?
(Jari) when using ESP to protect BUs, ESP doesn't protect source address.
(DJ) use it only when using ESP?
(Jari) possible, but introduces unnecessary dependency.
(DJ) Why not make it a required field? We end up with distinguishing between a BU for home and for non-home BUs.
(Jari) we already have that.
(FD) make it mandatory
(Jari) need to know whether it is ESP. Just make a requirement for home registrations. Don't try to solve an implementation problem by changing the protocol. Let implementors.
(Hesham) it's not a big problem, don't change it now.
(Rajeev) in FMIPv6 and HMIPv6 you need it.
(Charlie) leave it up to implementors
(Dave J) if you don't know whether you are using ESP you must use this.
(TJ) dynamic HA discovery question (56). Alternative proposal, if addresses don't fit in MTU, do it j-1 addresses and make j the address of the HA that is responding. Still get first optimization.
(Charlie) important to keep the first optimization.
(Hesham) prohibit site-local COA - no text is there.
(Erik) let's not say anything about site-locals
80 - (FD) R-bit is needed to say whether mobile node is a router.
Issues Dave Johnson wants to raise
(DJ) For RR the MN can't know whether the nonce is too old. An MN can send a BU requesting not to acknowledge. Can't get told nonce is too old. -> Need to be able to handle Binding Acks and match them with sequence numbers even in the case we did not request a binding ack.
(DJ) For RR, the cookie may be protected by ESP on HA-MN link. If it isn't protected anyone on or near the FL will see both cookies. Why not require ESP on MN-HA link?
(Jari) Previous discussion led us to believe it is a MAY. One of the reasons is that the kind of attacks that can happen will hurt MN-HA but cannot hurt third parties.
(DJ) disagrees - affects conversation with CN also.
(Hesham) thinks it's a SHOULD
(DJ) wants a MUST, reckless not to take advantage of required fnality
(DJ) will post rest of issues to list.
(Mr K) why do all nodes have to support HAO?
(DJ) for CNs to receive a packet from a mobile node while it is away from home.
(Mr K) this does not prevent communication.
(DJ) MN that sends a packet with HAO implies that all nodes must support it.
Fast Handoff in V6:
(Phil's pres on an 802.11 fast handoff draft)
Phil set the context and provided the background for the work and discussion. He also outlined a strategy for moving forward. Phils recommendation is that Fast HO be defined for specific link layers and we can start with defining Fast HO for 802.11
For details on the proposal refer to the slides.
- Hesham agrees. However a general protocol is all you really need.
Jak: Disagrees. Example of IPv6 in RFC2461 and 2464
Ohta: FMIPv6 useless. Document is large. 3G/FoMA is not valid for Internet access
Hesham: 802.11 work will raise the same issues all over again
Jim Bound: Agrees with the process proposed by Phil and supports it
Gopal: Doing the 802.11 spec will narrow the focus and help Gopal agrees that the 802.11 spec should simply specify the triggers
Rajeev: V05 already supports implementing FMIpv6 on 802.11
Hesham: Will the 802.11 draft simply specify the L2 triggers for fast HO?
Jak: The current draft is focused on Preaddress configuration and this is not possible in 802.11
(Jim) on network controlled handover. How does PAR know to send PrRtAdv without an L2 trigger? Only use when there is potentially no L2trigger, when MN sends a solicitation. Assertion: there is no way to do something like this without some kind of l2 info.
(Hesham) tunnel was previously terminated on the mobile node - now what happens with ingress filtering.
(Rajeev) question about what's available on L2?
(Jim) we are setting requirements
(Rajeev) are we putting musts for L2s
(Jim) there may be a tight coupling that needs to be specified.
- had to cut off the pres, Rajeev will post issues to the ML and solicit discussion from the WG on answers to his question.
VPN Traversal requirements
(Farid Adrangi presented the requirements)
(Raj) on RO, is it an objective to solve v4 R.O. (Farid) may
(Raj) what does RO have to do with this problem? If a new entity is introduced is rt. opt. needed.
Limited Private Address Support
(Gabriel's pres) new draft updates guidance for implementation of reverse tunneling
(Phil) what do you want to do with it?
(Gab) separate wg document as BCP or Informational
(Pete) concerned that implementation community is split because there are CDMA vendors who are doing separate implementations from what is done at Cthon. Existing RFC is a fine spec, pp2 understands what it means. Needs to review.
Some small mods. Ready for WG last call.
- Phil Roberts
- Basavaraj Patil
Mobile IPv4 Traversal Across VPN Gateways
Fast Handovers for Mobile IPv6: Proposed Changes
- Farid Adrangi
- Prakash Iyer
- Kent Leung
- Milind Kulkarni
- Alpesh Patel
- Qiang Zhang
- Joe Lau
FMIPv6 way forward
Limited Private Address Support For Reverse Tunneling In MIPv4