|
Combined Mobopts-Mipshop Meeting
IETF 63, Paris, August 2, 2005 Meeting Minutes taken by Christian Vogt, chvogt@tm.uka.de Tuesday, August 2, 2005 0900 - 0930 Morning Session I Room 352 or 353 1. Mobile IPv6 Route Optimization enhancements Christian Vogt, draft-irtf-mobopts-ro-enhancements-00/01.txt, 10 minutes 2. Handover Control Function Based Handover for Mobile IPv6 Yong, draft-cui-mobopts-hcf-wlan-00.txt, 10 minutes 3. Network-controlled fast handovers Telemaco Melia, draft-melia-mobopts-niho-fmip-01.txt, 10 minutes 4. Mobile IPv6 Fast Handovers for 3G CDMA Networks Hidetoshi Yokota, draft-yokota-mipshop-3gfh-00.txt 15 minutes 5. Mobile IPv6 Fast Handovers over IEEE 802.16e Networks Heejin Jang, draft-jang-mipshop-fh80216e-00.txt 15 min 1. Mobile IPv6 Route Optimization enhancements Christian Vogt, draft-irtf-mobopts-ro-enhancements-00/01.txt, 10 minutes [Official scribe was presenting; meeting minutes taken by Rajeev Koodli] 2. Handover Control Function Based Handover for Mobile IPv6 Yong, draft-cui-mobopts-hcf-wlan-00.txt, 10 minutes Hesham: How does the MN obtain the prefix for its CoA? Yong: HCF maintains a binding between AP MAC and AR prefix, and it sends it to the MN. Hesham: How can the CoA be checked? So you are saying there is no way to verify the EUI64 uniqueness. It's rare, but EUI64 may not be unique. Rajeev: There is no way to do DAD. 3. Network-controlled fast handovers Telemaco Melia, draft-melia-mobopts-niho-fmip-01.txt, 10 minutes MIP6 and current enhancements like HMIP6 and FMIP6 rely on handovers being triggered by mobile nodes. This work allows handovers to be triggered by the network. Telemaco: We would like to know whether this in scope of the research group. Yes. [ Handover Keys, James Kempf Was this presentation added to the charter? Can't remember. There wasn't too many questions according to my minutes, but I still don't want to skip the presentation in the minutes. Is someone authorized to do action typically associated with an IP address. ] 4. Mobile IPv6 Fast Handovers for 3G CDMA Networks Hidetoshi Yokota, draft-yokota-mipshop-3gfh-00.txt 15 minutes MIPv6 to be used in 3G network. Need seamless handovers, therefore fast handovers. Typically, MNs will be multi-homed and use different interfaces. This allows for smoother handovers. Bicasting during handover. Christian: Bicasting might confuse protocols at upper layers, like TCP... ...: There was a draft in Mobileip working group using the eifel algorithm to cope with packet duplicates and out-of-ordering. Rajeev: Planning to build experimental testbed? Yokota: Yes. ...: How bad is a handover without FMIP6? Right now, we can do it at layer 2, but standard MIP6 won't be efficient enough. ...: Seems that you need additional messages... Rajeev: When you use FMIP6, you can skip some messages, namely the ones shaded blue in the presentation. How about layer-3 information in layer-2 messages? Is this possible? Yes. Would it help? We can skip some layer-3 messages. ...: The trigger seems to always come from the BS. Is this always the case? Yokota: If the MN loses connection, MN can trigger handover as a fall-back. 5. Mobile IPv6 Fast Handovers over IEEE 802.16e Networks Heejin Jang, draft-jang-mipshop-fh80216e-00.txt 15 min IEEE 802.16e handover process consists of preparation and execution (2 steps). For the purpose of FMIP6, we extend this to four steps: new-access-router discovery, handover preparation, handover execution, and handover completion. Charlie Perkins: Assume a handover is successful, but there are no packets buffered. Since you don't use NACKs, how does the MN know that the handover was successful? Rajeev: There should be an FBACK in the successful case. Suresh: What kind of delay would you have, e.g., with EAPoL? Alper: There are other optimizations. You can authorize several base stations at once to reduce the delay. ************** Mobopts Meeting IETF 63, Paris, August 4, 2005 Meeting Minutes taken by Christian Vogt, chvogt@tm.uka.de Thursday, August 4, 2005 1030 - 1230 Morning Session II Room 351 1. RG status update, new topics (chair, 5 - 10 minutes) 2. "Link Characteristics Information for Mobile IP", SD Park and J. Korhonen, 10 minutes draft-daniel-mip-link-characteristic-02.txt 3. "LowPan Mobility Requirements and Goals", S. Chakrabarti draft-chakrabarti-mobopts-lowpan-req-00, 15 minutes 4. "Link Triggers and TARZAN implementation update", K. Mitsuya 10 minutes 5. "An efficient dynamic multicast agent approach for mobile IPv6 multicast", HK Zhang draft-zhang-mipshop-multicast-dma-00.txt, 15 minutes 6. "Seamless Multicast Handover in a Hierarchical Mobile IPv6 Environment (M-HMIPv6)", T. Schmidt draft-schmidt-waehlisch-mhmipv6-03.txt, 15 minutes 7. "MPA Framework and Implementation Updates", by A. Dutta draft-ohba-mobopts-mpa-{framework,implementation}-01.txt, 15 minutes 8. "Secure Proxy Neighbor Discovery using Multi-key CGAs", J. Kempf draft-kempf-mobopts-ringsig-ndproxy-00.txt, 15 minutes 9. "Improvement on Security and Performance of MIP6 Return Routability Test", F Zhao draft-zhao-mobopts-rr-ext-00, 15 minutes. 2. "Link Characteristics Information for Mobile IP", SD Park and J. Korhonen, 10 minutes draft-daniel-mip-link-characteristic-02.txt Vertical handovers can have grave impacts on performance, e.g., 802.11 <-> GPRS. Mobile IPv6 is the first technology-independent layer when different access technologies are used. Existing link-characteristic options (Seamoby) are currently only used between MN and network. ...: Assuming we use TCP or well-behaving UDP applications, those apps. would react to link-characteristic changes anyway. So why additional mechanisms? Gabriel: There are more situations in which you want to adapt to changed link characteristics. E.g., when link characteristics change even without a handover. You might end up using your optimization not nearly as much as you would want it. Jari: Interesting point is not about signaling link information to the other end, but using that link information there. Christian: You might be able to leverage mechanisms inherent in the transport protocol to react to changed link characteristics. E.g., with TCP, the MN could send three duplicate acknowledgements to the CN upon handover in order to trigger a fast retransmit [draft-eggert-tcpm-tcp-retransmit-now-01.txt]. This way, the MN wouldn't have to explicitly send link information over to the CN. This approach might not be as efficient as yours, though. Aaron: First, for a shared link, link capacity tells you little. How much is your share? Second, there is a related draft: draft-iab-link-indications. Third, there will be a new IRTF research group for congestion control. Brief intro at plenary tonight. Ryui: Also think about using link information on application level. E.g., streaming applications could increase frame resolution if link capacity goes up. 3. "LowPan Mobility Requirements and Goals", S. Chakrabarti draft-chakrabarti-mobopts-lowpan-req-00, 15 minutes Why is this different than "normal mobility"? - Not a fixed, static network - Layer-3 routing may not be done - Cannot count on a proxy like a home agent: Nodes are rather ephemeral and of low capability - IPsec is very heavyweight Goals - Sender responsible for finding alternate route - A node should be reachable as it moves across lowpan networks - Distributed architecture for information storage - Node authentication when node moves from PAN to PAN - Security is important *because* nodes are very small and communications can so be easily impaired Samita: Next steps with respect to this work? Rajeev: You should be clearer how you route packets within the PANs. Adding fast authentication is of potential interest to the research group. 4. "Link Triggers and TARZAN implementation update", K. Mitsuya 10 minutes See also software.nautilus6.org. Christian: Only 7ms for kernel-userland communication when the FNA is sent after the new link has come up? That seems to be too little. ...: It's not more than this. [Note from the minutes taker: I later talked to one of the implementors. He told me that there is a now a faster mechanism for kernel-userland communication in one of the more recent Kame-Shisa patches than the one I was using until now. - Christian] 6. "Seamless Multicast Handover in a Hierarchical Mobile IPv6 Environment (M-HMIPv6)", T. Schmidt draft-schmidt-waehlisch-mhmipv6-03.txt, 15 minutes Rajeev: You send the MLD subscription of the MN with the MAP? Schmidt: Yes, the MLD Report is tunneled to the MAP. Rajeev: You should also consider how the MN can prove ownership of its home address to a couple of CNs. Christian: You mentioned anticipation of handovers. What do MNs take into consideration for predicting a handover? Schmidt: It depends on the MN's movement pattern. Christian: Might also want to consider S/N ratio or flip flopping between access points. Rajeev: Implementation available? Schmidt: It's a Java program which we can make available to the group. 7. "MPA Framework and Implementation Updates", by A. Dutta draft-ohba-mobopts-mpa-{framework,implementation}-01.txt, 15 minutes Telemaco: I don't believe you get 4ms for L2 handoff. Ohba: Does not include scanning; this has been done before. 8. "Secure Proxy Neighbor Discovery using Multi-key CGAs", J. Kempf draft-kempf-mobopts-ringsig-ndproxy-00.txt, 15 minutes CGA prevents address stealing. Regular CGA allows single-key; multi-key CGA can be claimed by multiple hosts. Ring signatures are anonymous; you don't want to learn from the crypto when MN moved off link (and is henceforth proxied). Implementations are in the making. Rajeev: Is there an IPR on it? James: Yes, we have one. But if this becomes a PS document, it would be made royalty-free. Jari: Very interesting topic, not sure whether a PS or an Experimental RFC within IRTF. James: Yes. 9. "Improvement on Security and Performance of MIP6 Return Routability Test", F Zhao draft-zhao-mobopts-rr-ext-00, 15 minutes. Goals: increase security and reduce messages. Christian: You are doing this to get rid of the vulnerability to attacks from the path between the CN and the HA. But isn't there a new vulnerability to attacks on the MN-HA now? ...: No because the attacker wouldn't know what to put into the hash. Christian: Jari and I wrote a draft [draft-arkko-mipv6-binding-lifetime-extension-00.txt] which uses a hash chain to successively increase the time period between two HoA tests. It might be of interest to you. Rajeev: You do the initial HoA test, right? So what happens when you change the HoA? Do you have to do it again? ...: Yes. Christian: HoA tests are needed to prevent return-to-home flooding as well. It seems your proposal is robust to that attacks, but it's something to keep in mind. Rajeev: Summary and future topics of interest in the RG There seems to be interest in... - Network-control, network-initiated hanovers - Link characteristics - Multicast and mobility - Lowpan and mobility |