Last Modified: 2003-02-19
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.
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. |
RFC | Status | Title |
---|---|---|
RFC2005 | PS | Applicability Statement for IP Mobility Support |
RFC2004 | PS | Minimal Encapsulation within IP |
RFC2003 | PS | IP Encapsulation within IP |
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 |
RFC3344 | PS | IP Mobility Support for IPv4 |
efforts.Minutes for IP Routing for Wireless/Mobile Hosts WG (mobileip) Monday, March 17 at 1300-1500 ============================== CHAIRS: Basavaraj Patil <Basavaraj.Patil@nokia.com> Phil Roberts <PRoberts@MEGISTO.com> Gabriel Montenegro <gab@sun.com> Minutes by Nick Moore (sharkey@zoic.org) and Hesham Soliman (hesham.soliman@era.ericsson.se) with additional notes and edits by Gabriel. Abbreviations used: BA = Bernard Aboba BP = Basavaraj Patil CP = Charlie Perkins Erik = Erik Nordmark HS = Hesham Soliman JA = Jari Arkko JK = James Kempf MT = Michael Thomas TJ = TJ Kniveton TN = Thomas Narten ---------------------------------------- ---------------------- 1. Agenda and WG Document Status 10 Mins (Chairs) MIPv6 - last call completed IESG review (discussions ongoing) MN - HAsec: going to IESG AAA NAI: completed IETF LC Reg Rev: completed IETF LC WG LC: RFC 3012bis AAA keys for MIPv4 regional registrations : dormant Low latency: To go for Exp, no further progress since Atlanta LMM req: ready for WG LC Looking for security advice for VPN DT output (problem and solution draft) - Suggestions for draft-mccann.mobileip-80211fh-01 (informational?) - MIPv6 RO background (ionformational?) - New draft in dhc WG for MIPv4 (take a look) MIB status -- in the revision to 3044, would the associated MIB go to draft standard? TN: no, it advances like any other, going forward as PS. CP: regional regs is not dormant, there were good comments from alan o'neill and these were incorporated. So there has been some progress. Gabriel: If all the updates were made, we will look into it. ---------------------------------------- ----------------------- 2. Mobile IPv6 - IETF LC issues update 30 Mins I-Ds: o draft-ietf-mobileip-ipv6-21.txt [15] o draft-ietf-mobileip-mipv6-ha-ipsec-03.txt [15] (Jari Arkko, Charles Perkins) Jari on remaining issues. 273 - can a HA be CN at the same time? Suggestion: ignore a new BU with a different H value Hesham: This seems like a bug in the MN, maybe an error message should be sent CP: I would like to suggest the same. MT: Should CN->HA actually be illegal or is there a real situation where this could occur. JA: Could always delete the old entry before sending new binding. JA: It's clear that this is an error condition. 277 - what should CN do if H=1? Proposal: Clarify that RR be used if and only if H=0, and Silent discard if RR not used as expected. No comments. Suggestion seems acceptable 279 - NS src addr from HA to figure out the MN's addr Proposal 1: start answering NSes after sending the BU Jari: I prefer proposal 1 ??: agree with proposal 1 TJ: I also agree Issue 281 IESG Technical comments: Technical: different issues, no problem here. Issue 281 IESG Security comments: IKE should be a SHOULD; some work required. TN: needs to be a discussion, security people need to describe _why_ it should be a SHOULD. MT: Should not be mandatory on IKE, but on some flavor of key mgmt (there's others besides IKE like kink). Not necessary to single out IKE. BA: IKE will only work with IKEv1 cuz only aggressive mode could be used (main mode), and then the handling of fragmented packets won't work, ikev2 won't fix this, you end up with 1/8 of a key mgmt CP: sequence number already does replay protection for several years (potentially) using preconfigured keys. 278 - movement detection HS: proposal #1 (ignore the issue) is reasonable and simplest, No point in complicating these algorithms now. A MN can change CoA based on new prefix or ll address change. JK: agree Ed Remmel: R-bit should be a MUST not just for HA's but for all routers Charlie: The solution is different depending on the link type. No one size fits all. A mandated solution could hurt performance on some media It would be a lot better to leave it as is. TJ: I agree with everything said so far. Now is not the time and place to fix this. Erik: If people implement this from the spec and doesnt work then it would be useful to mention the problem in the spec to reduce the probability of errors in stacks. TJ: Are there common cases where routers configure the same ll address on different interfaces? Erik: If there is one then that's enough. Vijay: Some implementations use Eager switching and some don't. There are many different ways of doing this. There is no need to fix this in the spec. Some warnings are enough. Perhaps the new MIP WG charter should address this. BP: This needs in a different doc. From this discussion I would say leave it as is and document the problem. ---------------------------------------- ----------------------- 3. Connectathon Update on Mobile IP protocols 10 Mins (Samita C.) All implementations supported rev 20. 2 implementations supported IPsec between MN and HA based on WG draft. A discussion for MIPv6 Internet testing. A mailing list will be setup. Presenatation at www.connectathon.org. no major issues, just simple clarifications currently resolved TJ: there were also 3 implementations on prefix discovery on home link. First time this was interop tested and it was successful. ---------------------------------------- ----------------------- 4. Registration Revocation in MIPv4 - LC issues update 15 Mins I-D: o draft-ietf-mobileip-reg-revok-05.txt (Steve Glass) * CLARIFICATION: That's 1 revocation PER BINDING PER SECOND. No questions asked. ---------------------------------------- ----------------------- 5. Mobile IPv4 Traversal of VPN Gateways update 15 Mins I-Ds: o draft-ietf-mobileip-vpn-problem-statement-req-01.txt o draft-ietf-mobileip-vpn-problem-solution-00.txt (Gopal Dommety, Sami Vaarala) Gopal on vpn design team Problem statement essentially done MT - do any of your solution allow an IPsec tunnel to replace the MIP ip-in-ip tunnel? Gopal - we don't do this cuz you'd need the HA in your DMZ MT - so? in that particular situation it would be beneficial Gopal - it's implicitly allowed, yes. ? - how does this mesh with nat traversal? Henrik: If you wrap the IPsec tunnel in the MIP tunnel then it will work through NAT. They are two different things that can work together or by themselves. CP: It's always been possible to put IPsec with IP in IP tunnelling. Gopal: We assume no protocol changes Charlie: Why can't the HA put IPsec over the tunnel? It was never prohibited in RFC 2003. You can already do that without protocol changes Gopal: MIP is terminated at the VPN GW Charlie: But you could also terminate it at the HA Henrik: What Charlie suggests is resonable if you have a VPN GW with a HA together in one box. Charlie: Ok, so no protocol changes are needed. ? - how much is applicable to ipv6? Gopal and BP - not currently targetted, this is ipv4 only work ---------------------------------------- ----------------------- 6. Fast Handovers for Mobile IPv6 - Issues 10 Mins I-D: o draft-ietf-mobileip-fast-mipv6-06.txt (Rajeev Koodli) tunnel establishment hi/hack only after processing fbu less state to keep revised fna issue: how to secure FBU depends on trust MN-PAR MT: What is the difference between MN-HA security association and MN-PAR relationship anyway? Why the different mechanisms? JK: Possible answer for this by ending tunnel in NAR, needs further discussion. HS: Why we can't use IKE: address ownership problem. CGA's would work, otherwise it's hard Alper: Roaming node may need many trust relationships maybe use SEND mechanisms? Rajeev: must be a solution in the FMIP draft. CP: Two cases: how do you set up associations, how do you transfer `associations? JK, HS: Draft can't advance until security at least referenced. Erik: Maybe as _experimental_ without security. Maybe it's possible to build a shared secret to authenticate MN to PAR communications. via PBK/anonymousDH. ---------------------------------------- ----------------------- 7. Optimistic DAD and Non-Predictive Handovers 15 Mins I-D: o draft-moore-ipv6-optimistic-dad-02.txt (Nick 'Sharkey' Moore) Erik: Will the router override send packets to the optimistic node if an entry already existed for anothe node? Nick: Based on experiments I found that it will continue to send packets to the old node, not the optimistic node. Thomas: There is a problem with a packet sent to foo and received in another node then that node might RST the TCP connection Nick: It won't happen, the node does not override an exisiting entry. James: How do you get Fast RA if you don't have L2 triggers? Nick: Fast RA just means answering the RS without delay. BA - good papers on arbaugh on delays caused by scanning, but l2 on802.11 now seen as little as 40ms Hesham: So is it fair to say that the difference between predictive and non-predictive handovers is the L2 handovers? Nick: Yes. Charlie: Did you use 400ms with piggybacking mode? Nick:..... missed it Charlie: Is there something that needs to be specified in the piggybacking draft. Nick: If you don't have outoging traffic then piggybacking can be harmful. Erik: So do you assume that the delay to the MAP is zero? I.e. the MAP is close to the MN? Nick: Yes we assume that the MAP is pretty close to the MN, which is true in many cases. Maybe not all. Rajeev: So you still have some packets going to the old AR till the BU arrives at the MAP? Nick: Yes that's right. ---------------------------------------- ----------------------- 8. Extension to Sockets API for Mobile IPv6 10 Mins I-Ds: Samita on draft-chakrabarti-mobileip-mipext-advapi-00.txt -------------------------------------------------------- No comments Alper on draft-yokote-mobileip-api-01.txt ----------------------------------------- There is an IPR statement on this draft but it will be removed in the next revision. No |