Mobility EXTensions for IPv6 (MEXT) Working Group Chairs: Julien Laganier Marcelo Bagnulo Meeting minutes based on notes taken by Wesley M. Eddy and William Ivancic. ------------------------------------------------ MONDAY, November 17th, 2008 ------------------------------------------------ RFC 3775bis Issues - Charlie Perkins - many closed issues - also many open issues; hope to close a lot today - issue #2, not addressed here; seperate discussion & draft (DHAAD-harmful) *WILL BE CLOSED LATER IN MEETING (last 15 minutes)* - issue #7, dsmipv6 bu & RFC3775 (enhancement) Charlie doesn't know what to do and doesn't care. We will solve it today. Raj Patil likes proposal #2. Hesham likes proposal #3. (lifetime = 0) Claims it is not just a DSMIPv6 problem. Vijay Devarapalli likes proposal #3. Claims that most people are doing it. *VIJAY WILL PROVIDE TEXT ON PROPOSAL #3* - issue #9, simultaneous mobility (defect) Nobody has observed this in practice, it may be a rare case that doesn't require a solution. There are multiple proposals and possibilities, but none are clearly winners. Raj Patil thinks we should pull RO out and publish separately, fixing this problem there. Julien proposes to leave it as an implementation issue. Hesham says we can explain the tradeoffs. *HESHAM WILL SUPPLY CHARLIE WITH A ROUGH DRAFT OF DESCRIBING TRADEOFFS OF DIFFERENT METHODS TO DETECT WHEN TO FALL BACK TO REVERSE TUNNELLING* - issue #10, ready to close, usage of HA lifetime (defect) ACCEPT BENJAMIN LIM'S PROPOSAL - issue #11, de-registration when returning home, ready to close text is on issues page, discussion was >1 month ago *ACCEPT PROPOSED TEXT ON MEXT ISSUES PAGE* - issue #15, brr sent by HA too (enhancement) there are objections to the proposal due to new functionality and increased signaling danger, Charlie thinks we should not do this Hesham - should it be allowed, is a different question than making it a MUST. could send 0. Raj Patil asked clarifying questions Jari Arkko - HA binding is very different than the CN one; no scenario where the HA sending BRR is useful. *THIS ISSUE WILL BE CLOSED WITHOUT CHANGING THE DOC; HA WON'T SEND BRR* - issue #16, ha behavior when MN returns home (defect) arguments can be made for both sides Marcelo - if nobody cares, and it's not an error, we won't do anything Hesham - we care, it's just difficult to solve; there may be times when we can't maintain backwards compatibility Charlie - if it's rare, we don't want to penalize the protocol Hesham - it may not really be rare Charlie - in order for this to makes sense, MN has to keep SA, prefix, other state, but forget its binding Raj - could be put in non-volatile memory Julien - how about whenever you boot, on the home link you deregister Hesham - if you use bootstrapping, you might get a different HA Julien - this has to be discussed in context of bootstrapping. Suresh Krishnan - understand question, but not point; binding has a lifetime and will go away, what is the problem? Charlie clarifies. Vijay - if you reboot, you loose HoA but not HA and will be given the same HoA back. Ahmed - don't know why this is specific to MIPv6, MIPv4 has same issue. Charlie - you're right that it exists in MIPv4 and it's never come up there. Vijay - the way most people have deployed, it can never be on home link Marcelo - do we care about this; do we want to solve it or not? none raised hands to do something about it *ISSUE DROPPED* - issue #17, multi-homed mobile node causing routing loop between HAs Hesham - IP-in-IP has tunnel-limit option Suresh - a lot of people previously said this is not an issue in real life. Charlie - it hasn't been seen in MIPv4 Vijay - tunnel-limit is an option, not required. in 3775bis, we can say to use it if you expect to deploy in a vulnerable setting. Suresh - agree with intention, but how do you write a compliance test, it should be a SHOULD Raj - deployment has no idea if this scenario is true Hesham - we can't frame any solution in terms of if the HA thinks the MN will be multihomed. It's normal for an implementer to have to figure out when to implement this themselves. Jari - going forward it would be useful to mention this in the security considerations; not sure the situation calls for requiring it. Mention possibility of loops and one tool that can deal with that. Vijay - proposed text for this issue that does EXACTLY that ??? - should look into other proposal as well (draft-ng-intarea-tunnel-loop) The RFC is designed to limit tunnelling, but doesn't detect the loop or take corrective actions itself. Suresh - if it's a problem, we need to mandate it because BOTH HAs have to do it for the solution to work (requires cooperation). Behcet - MIPv6 single instance can talk to single HA and if you want to talk to more than one HA, you need more than one instance Charlie - HAs aren't even aware; separating into two stacks doesn't solve this at all Julien - question to Suresh, N home agents and one implements this, it will work, it just takes N-times longer to work. write it down in security considerations. *WILL INSERT NEW TEXT IN SECURITY SECTION WARNING OF PROBLEM AND SUGGESTING TO USE RFC 2473* - chairs will send an email confirming all directions forward on mailing list DHAAD for MIP6 - Raj Patil - this concerns the update to RFC 3775 bis (issue #2) - issue: MN being aware of home prefix is generally not the case; security concerns with use of ICMP; bootstrapping available via IKEv2 & DHCP options - question for WG is whether to deprecate DHAAD Raj would like to deprecate Sri - is there anything to say why it might be useful? Within an enterprise deployment it might be valid and this could help. Suresh - you don't need to implement bootstrapping to be compliant to mipv6, but you do have to implement dhaad; I'm happy to have it broken out to a separate document Raj - this was never designed for reliability or load balancing Sri - capability exists; you take out features when they break things, but not otherwise Hesham - need to consider criteria for removing and whether it's useful or not. For removing, I think this won't be widely deployed by the time of Draft Standard. It's inferior to the other mechanisms on any level of comparison. Security, load balancing, etc. Alper - makes sense to separate, bootstrapping is not fundamental to the core of the specification; can survive as supplementary. Ryuji - if DHAAD is separated from 3775bis, will we have a reference to it or not. the feature is needed by the ha-reliability doc. How much text are you going to remove, just DHAAD or all related features. Many features are equally not used, so that's not valid criteria to remove this. Raj - part where mobile sends anycast message to receive list of HAs is only one to remove. Suresh - putting too many things together here. neutral on putting it in 3775bis, but don't want it in future docs Julien - think it's fine to keep it, but not continue extending for it. Taking it out is a lot of work for nothing; why go out of our way to take it out. Raj - to reduce size of MIP6 implementation Jari - if we are talking about removing something because it's not useful anymore, the bar has to be relativly high (most of WG in agreement). 3rd option of moving it to another doc is extra work, a little worried about them getting longer. Could use a keyword (MAY) and keep it. Vijay - don't think feature is useful enough for MUST, but could mention it as optional feature with other references to bootstrapping work Vidya - no opinion on feature removal; observation on consistency, we say we want to simpify on client side, but that means it has to be mandatory on HA. We say that there are other mechanisms defined, but then there are also proposals to deprecate parts of those ... C. Perkins - effort to make it into a separate doc could be met by those energetic to remove from this Vidya - shouldn't go down the path of making separate docs; this is a pretty insignificant feature, that should just be optional or removed. Ahmed - don't know what neutral means ... discussion of what the proper poll options to take are. Marcelo - who wants to keep it mandatory on both sides? (Sri) Marcelo - who thinks it should not be mandatory in some flavor? (lots of people ~15) Marcelo - who thinks it should be optional in both? (lots of people ~17-19) Marcelo - who thinks it should be optional in MN, mandatory in HA? (4) *DECISION TO MAKE OPTIONAL IN BOTH; TO CONFIRM ON MAIL LIST* ------------------------------------------------ THURSDAY, November 20, 2008 ------------------------------------------------ Discussed deliverables: See IETF meeting materials http://www3.ietf.org/proceedings/08nov/slides/mext-9.ppt Accepting comments for RFC3775 for next month than Last Call. DHCPv6 Prefix Delegation for NEMO http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt Ralf - 5 min http://www3.ietf.org/proceedings/08nov/slides/mext-8.pdf Ralph Droms presenting: Added detail in Security Considerations for protecting traffic between the DHCPv6 relay and server LAST CALL WG last call on draft-ietf-mext-nemopd-01 in progress www.ietf.org/mail-archive/web/mext/current/msg02196.html Charlie Perkins conclusion that DHCP in base spec. In this nemo spec consensus in on to be in nemopd. Discussion on extending DHCP. So DHCP will not be included in nemopd. Julien, Hesham Soliman and Sri text needed to describe DHAAD on how to find HA. Need section that says if MR doesnt get prefix then try somewhere else. Julien requests more detail on how to configure DHCP and IPsec. Magesh ? Question regarding handovers. Move to IPv6 domain how HA prefix deligation from Mobile Network prefix. Restate how to move from local network mobility to nemo. Request to take question to netlmm meeting tomorrow morning. Binding revocation http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-01.txt Ahmad - 15 min http://www3.ietf.org/proceedings/08nov/slides/mext-3.ppt Disussion by numerous people Sri, Julain, Charles Perkins at microphone on BRI Packet Dest. Address. Which IP address to use int eh BRI IPv6 packet as the destination IP address. Charles Perkins, Sri no change in 3775 or what? Does RFC 3775 need change or clarification? Microphone discussions Hesham Solimans point is binding acknowledgement different the binding recommendation. There is really only one address available to send to for binding revocation. According to current specification, there is no choice. There is only one home address to send to. More discussions at microphone there is nothing in RFC 3775bis that clarifies this issue. It is not trivial change. Discussion should go to mailing list. If changes needed to RFC 3775 take to RFC Issue tracker. Working Group last call delayed until this issue is resolved. Binding Revocation using Auth option http://www.ietf.org/internet-drafts/draft-muhanna-mext-revocation-using-authoption-00.txt Ahmad Muhanna - 10 min http://www3.ietf.org/proceedings/08nov/slides/mext-4.ppt Adopt the draft as a WG or AD sponsored Informational doc? Request for input. Microphone discussion of need. Will definitely be useful for WiMax Few read draft. Those the read draft Suresh Krishnan draft is reasonable condition. Question is Is there a need? So far two hands said needed. Consensus from reading from the room is this is not needed. Who thinks we need revocation option for BRI. About equal 5/4 need to not need. There are people using this. Extended home link support for DSMIP6 http://tools.ietf.org/html/draft-premec-mext-extended-home-link-00 Domagoj - 15 min Basavaraj Patil presenting for Domagoj http://www3.ietf.org/proceedings/08nov/slides/mext-2.pdf Hesham Soliman Need to separate IPv4 and IPv6 lifetimes. Need to decouple binding lifetime. Julien what is needed I separation of binding cache enteries Hesham Soliman that is implementation issue. Tunnling v4 over v6 and visa versa is specified elsewhere. Discussion at microphone regarding implementation and ambiguities. Appears to not be a problem. Questions should be working group draft? Initial consensus looks promising. Will take to mailing list. Issues related to the design choice of IPsec for Mobile IPv6 security http://www.ietf.org/internet-drafts/draft-patil-mext-mip6issueswithipsec-00.txt Raj - 20 min Charlie Perkins presenting http://www3.ietf.org/proceedings/08nov/slides/mext-5.pdf Scalability of IPsec SAs at HA is very difficult. IPv6 nodes ARE being deployed without IPsec and most definitely with IKEv2. Hesham Soliman use of IPsec is annoying in MIPv6. Need to address what is annoying and what is not. NAT traversal has two NAT traversal running at the same time like for MIPv6 and IKEv2. Vidia Arguments are not convincing in the lease. Every STO that have implemented MIPv6 have IPsec and IKEv2. Martha ? If there are requirement for IPsec IPv6 please let Martha know. She will send request to mailing list. Microphone discussion on wired interface. Is signaling a problem? It depends. For most, probably not as there is enough bandwidth and not that much signaling. For others it is. Conclusion from Charlie is IKEv2/IPsec is causing some barriers to MIPv6 deployment. Jari As someone who was on design team. Takes part of the blame. If design was done now, probably would done something besides IPsec. Do not agree with all of Charlies arguments but agrees with some. Need to make the right arguments or credibility is questioned. If we want to do something better need other good alternatives. Vidia What is the key issue? Agree with Jari. NAT traversal is problem. Do not let every implementer do there own key exchange protocol. What about interoperability if multiple security mechanisms were permitted? Jari does the working group even what to do this and does the group have the energy. Analysis on how to address NEMO RO for Aeronautics Mobile Networks http://www.ietf.org/internet-drafts/draft-bernardos-mext-aero-nemo-ro-sol-analysis-00.txt Carlos - 15 min http://www3.ietf.org/proceedings/08nov/slides/mext-7.pdf No comments. Tunnel Loops and Its Detection draft-ng-intarea-tunnel-loop-00.txt Mohana Jeyatheran presenting http://www3.ietf.org/proceedings/08nov/slides/mext-6.ppt This problem was dealt with on Monday and solutions appear to already exists for MEXT case.