Last Modifield: 08/08/2002
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.|
|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|
IETF55 Mobile IP WG meeting November 19th, 2002 (1930 - 2200) ################################## Chairs: Basavaraj Patil Phil Roberts Gabriel Montenegro Ack: Thanks to Alper Yegin and Samita Chakrabarti for contributing these meeting minutes. Minutes ======= Agenda and Document Status ************************** Meeting agenda presented by Basavaraj. Introduced the new co-chair Gabriel Montenegro to the WG. WG document status presented by Phil Roberts 1. The WG is currently working on advancing RFC3344 and RFC2794 to DS. Interop data has been collected. 2. IESG approval for the MIPv4 NAT traversal I-D has been received and should be on the RFC-ed queue soon. 3. Mobile IPv6 draft 19 has been released. AD comments have been received by the WG. 4. WG last call completed on the following I-Ds: - rfc3012bis, - AAA Keys, - QoS requirements (this I-D has been handed off to the NSIS WG), - regional registration for Mobile IPv4 (authors addressing last call feedback), - registration revocation for Mobile IPv4 (awaiting AD comments), - FMIPv4 (experimental) and - MIPv6 and IPSec HA-MN interaction (comments being addressed by authors). 5. WG I-Ds ready for last call: - LMM Requirements - AAA NAI for Mobile IPv4 6. Work in progress - Mobile IPv6 I-Ds, FMIPv6 and FMIPv6 for 802.11 , HMIPv6 and LPAS Mobile IPv6 issue status and discussion *************************************** Jari Arkko and Charles Perkins Status as of draft version 19: - All issues resolved - HA-MN IPSec was produced - Comments received from AD- will go to last call soon - 102 Issues (12 rejected, 90 adopted, 6 major issues, 30 minor, 30 medium, 24 editorial) New issues have been filed since AD comments were received Primary focus on AD comments at this meeting. Issue 163: Run MLD between the MN and HA. Text has been proposed and agreed on the mailing list Issue 159: D bit semantics: who should be responsible for knowing when to do DAD? Proposal: remove the D bit, and let the HA initiate DAD unless deregistration or defending the home address. Agreed on the mailing list. Issue 156: Conflict with ND and DAD Proposal: Produce a separate doc on optimistic DAD Issue 158: When to start RO Recommendation: Produce a guide line when to start RO by the MN, this guideline will/should be a result of experience gained with experimentation and interop testing Discussion Basavaraj: it depends. If CN has no binding, no RO even after you move. Erik: If CN already had state (binding cache), you want to immediately update after movement. This case should make a difference. Thomas: there are a lot of things to think about "when to do RO". You might want to give some guidelines. Issue 160: HA discovery should not assume single address of a HA Proposal : Let DHAAD return all addresses of each HA Issue 150: Failed de-reg when returning home (addressed ) Issue 157: Address collision action Disable the interface and wait for reconfiguration when DAD fails. This is a drastic action. Where to fix this action? At SEND WG? Should we update IPv6 ND spec? Or, MIPv6 spec? No consensus on the mailing list. RFC2462 says disable interface and wait (drastic action for Mobile situation) Options discussed: 1) Let SEND deal with this 2) Generate private address (RFC3041) when address collision happens Comments: What if SEND and non-SEND nodes are on the same subnet ? Malicious case: Can't do much unless it is authenticated Normal collision: Rarely happens, is it worth worring about ? Folks seem to prefer option 2) for MIPv6 case. Issue 154: ND constant tuning differs from ND Options: 1) Let IPv6 wg change ND doc and remove reference from MIPv6 2) Write a separate draft 3) Both above There has been long discussion on this topic. Mostly working group members are in favor of not removing the MIPv6 specific ND constants from the base draft as they are quite important for MIPv6 operation. ADs recommended a separate draft. Dave Johnson suggested that keep the information in the MIPv6 doc now and remove later when alternate document is available. Otherwise the information could be lost. Chairs supported this idea. Discussion: Charlie P.: cost of modifications are not needed for all routers, just for those supporting mobile nodes. We can have documents that people can implement and get good results. Bob Hinden: these changes are fairly generic. Let's bring them back to IPv6 WG, as extensions to ND. It's not a special case, it's a normal case. Jari: most routers will have to do these. Hesham: link-layer indications are not generic. Also, all routers need to implement these, as a router may serve mobiles at any time. James Kempf: there are things that are specific to mobile nodes, not all nodes will be mobile node. Wireless links are different. Charlie P.: it's a tunable parameter. It's a mistake to bury tunable parameters in another document. Greg Daley: I don't have opinion on which document should cover these. It's MIP's responsibility to look after these issues. It should be done in MIP (WG). Basavaraj: if frequency increased, what's the problem here? Erik: One issue: how frequently sent unsolicited RAs? Other issue: how frequently can they sent solicited RA? It makes sense to talk about applicability of these things. Brian: we can even add new options, but why can't we change existing ones? Thomas: these changes need to be reviewed by the IPv6 WG. We can get an updated doc. in 6 months. Gabriel M.: what if IPv6 WG not like it? Thomas: either way. they can oppose it during the last call. Thomas: I think these apply to all nodes. Split up things. Dave Johnson: We discussed this at the IPv6 WG. It was approved. Now it's being re-opened. Why the consensus established is no longer valid. Also 6 months is too long. And 6 months is not accurate. Thomas: consensus depends on the last calls. Basavaraj: this WG believes 50ms is the right time. This WG made a decision. Now we are speculating the IESG last call might have problems. This is speculation. Everyone at the IETF will have a chance to review this at the last call. Erik: modular specification is better. If we had realized that earlier, we could break MIP spec into several protocols, home agent discovery, etc.. Bob Hinden: IPv6 WG is your friend. Bob Hinden: Router builders won't see this spec. 50ms makes me nervous. In productization, adding more features in a product slips the release date. Charlie Perkins: this is a well understood technique. Jim Bound: products can slip, but not for 6 months. Phil Roberts: there might me more than this comment during the last call. This group of people prefers to leave it in. Thomas: please clarify what things will be left in. Phil R.: only advertisement interval. Thomas: how about the wait before sending solicited RA? some people: both. Greg: fastRA proposal should be handled separately. Decision: RS/RA intervals as specified now will be in MIPv6 draft although they differ from ND doc at the moment. Issue 151: MIPv6 and DHCPv6 -Does it work ? If MN follows DHCPv6 spec, does it get a DHCPv6 address assigned by HA ? Question: Does it need to be fixed before last call ? Thomas: MIPv6 should not preclude DHCPv6, at least an investigation should be made if MIPv6 protocol is able to handle DHCPv6 as it is or upon minor enhancement. Issue 162: Site-local addresses - should we allow it ? - Currently only on disconnected sites. Will update after ipv6 site-local discussion. Mike: is the main issue with route optimization? Charlie: initial discussion was about what addresses are legal in routing headers. Mike: a compromise might be to forbid RO with site-locals. Bod Hinden: just use gloabl for now, wait for IPv6 to decide. Charlie: this is pretty restrictive. Fast handovers for Mobile IPv6 over 802.11 ****************************************** Pete McCann - draft-mccann-mobileip-80211fh-01.txt 802.11 needs to handle FMIPv6 situations. Implementing exotic device drivers ? Is the signal-to-noise ratio information truly real-time or is it just updated every n sec ? 802.11 trigers: -contains old AP and new AP MaC address - enables IAPP operation Discussion: Anticipation is difficult. firmware/driver makes autonomous real-time handover decisions. Hesham: firmware makes this decision based on SNR? Pete: yes. proprietary mechanisms. But not impossible. HostAP or SoftWiFi model supports this. Exotic device drivers support this. Not possible with all cards. James: no way around to scan. scanning is costly. you can put in adhoc mode, this can be a solution. Pete: you can rewrite the scan mechanisms. Bernard Aboba: no specifications in this field. behavior is variable. But this is not necessarily a problem. Gopal: some nics allow you to associate with to APs. Pete: this is againist the spec. Bernard: you'd have two macs, and learning switches will take care of it. Rajeev: motivation is not to disallow this feature where it's available. People claim they are doing this in the experiments. James: we couldn't do it. Bernard: some nics don't use SNR. James: we cannot fix this here. Hesham: exactly. if your nic can do that, use fmip, if not, bad luck. Security: WEP ? 802.1X? (secure but not fast enough across subnets) PANA? (Not ready yet) Both 802.1x and PANA require anticipation. Bernard: pre-auth allows anticipation and reassociation does not always imply final decision. Next Step: It was recommended that more work is needed at IEEE for 802.11 to support MobileIP. Pete asked if this work should be a working group item. Fast handoff draft needs some updating to reflect 802.11 fast handoff. Discussion: - is anticipation realistic? James: if no anticipation, no benefit. Hesham: informing people about what information needs to be passed up. Rajeev: distance of CN is also essential. Bernard: IEEE is like IETF. if you are willing to go there, perhaps you can get some of thes things. things inside the host is not as interesting. - relationship of PrRtSol to CARD? Open issue - Fate of this draft? - To be discussed further on list FMIPv6 Update ************* Rajeev Koodli - draft-ietf-mobileip-fast-mipv6-05.txt tunnel can be established by - prrtadv - L2 indication - FBU Forwarding on the tunnel started by FBU. From mailing list discussions: - move prrtsol/prrtadv to and earlier time - allow prrtsol to include a wildcard, dowload info for all neighboring AP-AR. Hesham: we have a security problem. we need to solve that. James: concerned about CoA configuration. James: Concerned about FBU assumptions. With my IAB hat, I'm concerned about the architecture here. Two types of mobility here. Alternatives to FBU along the line of ND, ICMP redirect need to be considered. Design Team status on MIP traversal across IPsec VPN gateways **************************************** ********************* Gopal Dommety steps: - define problem statement (finished) - get WG blessings on the problem statement (to be done) - work on high level solution with IPv4 focus (to be done) objective: seamless IP mobility across VPN. (VPNs for remote access, or encrypting traffic. ) case: - HA inside the enterprise, inside the VPN domain. - MN inside the VPN domain, HA on the Internet. (only problem when the MN inside the VPN domain). Solution guidelines: - none or minimal IPsec changes - no changes to vpn/dmz architecture - minimize software upgrades solution options: - using dual mobile IP layering. one inside, one outside the DMZ. - use of proxy entity which is mip aware - making vpn concentrator accept outer IP address changes without breaking IP security. - use IPsec tunnel instead of GRE/IPinIP tunnel. RFC3012bis Issues ***************** Jayshree Bharatia - draft-ietf-mobileip-rfc3012bis-03.txt Jayashree discussed the issues and proposed clarification text for rfc3012bis in response to AD comments and mailing list discussions. The details are available in the slide presentation. There was no objection on the changes proposed. HMIPv6 Update ************* Hesham Soliman - draft-ietf-mobileip-hmipv6-07.txt changes: - removed extended mode. - updated BU format based on the base spec. - MN allowed to perform RR to CNs. - described how the MN establishes an SA with MAP in detail. removed chapter 9: single message including two BUs. specify timeouts and local retransmissions of local BUs. need for another MAP discovery mechanism. Question to the group: current scheme assumes that there is no need for testing the CoA in order to authorize the local BU. MAP is similar to HA. Is this assumption correct? IPR only applies to Dynamic MAP discovery. Erik: if LCoA is not limited, then attacker can launch an attack on victims outside. Hesham: We discussed this, but We don't have it in the draft. Three way handshake is an option. Connectathon ************ Samita Chakrabarti www.connectathon.org registration deadline: feb 7, 2003 will focus on mobile IPv6 testing. no mipv4 conformance testing, only interop on mipv4. mobileip-ipv6-19 mipv6-ha-ipsec-01 rfc3344 rfc3012bis rfc2794 rfc3024 other? Proposal: How about mipv6 interop test bed on 6bone? for continuous testing. Charter Revision **************** Gabriel Montenegro outlined the charter revision proposal. The charter has been discussed between the chairs and the ADs and the outcome is as follows: current charter/milestones outdated. There is a desire for better focus. different maturity levels, mipv4 vs. mipv6. different goals: mipv4: deployment. mipv6: finishing basic functionality (and optimizations). (mostly) different constituencies. Current WG has a split personality. Split into 2 WGs: - mipdep WG: mobile IP deployment WG. not mipv4 specific., focus on mipv4, but mipv6 also ok. operator issues. other SDO's requirements for deployment. - mipv6 WG hopefully short lived WG. narrower charter, better focus. mipdep: vpn lpas mai extensions challenge-reponse. registration revocation mibs mipv6 wg: - mipv6 spec. - bootstraping - modularizing mipv6 spec into smaller specs - some optimziations - hmipv6 - fmipv6 - ND modifications - movement detection - simultaneous bindings - optimistic/fast DAD, router discovery. Questions: drafts will mostly be moved and adopted automatically. Charles: would new attempts to develop mipv4 related protocol be discouraged if not related to deployment? Basavaraj: they are not prohibited. George T.: some deployment points to new protocols. Hesham: what was the justification? Gabriel: split personality. Hesham: why hmipv6/fmipv6 are experimental? what is the criteria do decide something is experimental. Basavaraj: determination should not be arbitrarily set. interest level, and implementations are important. James: these technologies need to be tied into real-life deployments. Gopal D.: agree with the split personality problem. it's better to split mipv4 vs. mipv6. George T.: are we opening the flood gates? one meeting per IETF was controlling it. Samita: split is good, but... mipv4 and mipv6 is a better idea. Phil Roberts: we'll be discussing this on the mailing list. no timeframe yet.