MIP4 WG Meeting, March 23 2006, IETF 65 --------------------------------------- Document Status --------------- Hesham: Comment on adopting new work Is there a plan to take new drafts ? Is it a good time: Pete: Lets go thru the doc status draft-ietf-mip4-rfc3344bis One minor nit found (Selector for the MN-HA SA) We need one more spin of the document, some errors in the selector being CoA vs. Source IP address draft-ietf-mip4-vpn-problem-solution Ready for WG last call (Will be started on Monday 27th) draft-ietf-mip4-dynamic-assignment RFC 4433 draft-ietf-mip4-faerr Approved by the IESG draft-ietf-mip4-reg-tunnel Dead The draft has been re-submitted without the Appendix. Waiting for chairs' writeup. draft-ietf-mip4-rfc3012bis IESG Evaluation :: AD Followup Several reviews done for AD, Decided not to fork off the Generalized Mobile IP Authentication Extension as a separate draft. Scathing review from Elwyn Davies was very critical of the draft. Addressing the concrete points is not much work Requires the chairs and the AD to decide on the plan with respect to the draft. Waiting for AD guidance draft-ietf-mobileip-lowlatency-handoffs-v4 RFC Editor's queue Dependency on reg-tunnel draft-ietf-mip4-rfc2006bis MIP-centric review done, new revision needed Kent: Will try to submit a version by the end of the year draft-ietf-mip4-mobike-connectivity-00.txt Ready for WGLC? (Preliminary date: 17 April 2006) ? from checkpoint. there are too many solution documents one with three tunnels, one with two tunnels and then this. It is too confusing for a reader. Vijay: we tried to clarify this in the current draft. It has an applicability statements on when this solution should be used. Please suggest any clarificatios that you want to see. Henrik: Does the document refer to the two other VPN drafts (problem statement and solution)? Vijay: Yes. draft-ietf-mip4-message-string-ext-00.txt Ready for WGLC? (Preliminary date: 8 May 2006) Pete: Message String extension We can go for last call soon draft-ietf-mip4-radius-requirements-00.txt Ready for WGLC? (Preliminary date: 29 May 2006) draft-ietf-mip4-fmipv4-00.txt Ready for WGLC? (Preliminary date: 19 June 2006) Vijay: A general comment on 3012bis. Sometimes the reviewers from Gen-ART might not be aware of the all issues, all the reasons for design decisions, etc., and sometimes deliver scathing reviews. We should consider that when we get reviews. Jari: Gen-ART reviews help the IESG make a decision. But the review will be taken only as an input into the decision process. In this particular case, I agree with the review, there are issues, but since this a bis document revising an existing RFC, I am fine with this going ahead. Network based mobility support ------------------------------ draft-leung-mip4-proxy-mode-00.txt presented by Kent ---------------------------------------------------- Hesham: Dont see why one cannot just sell MIP4 client. Vendors sell VPN client and why not MIP client? Henrik: Providing and selling a Mobile IP client depends on whether a particular vendor controls the client or the mobile device. The customer for this is the company that makes network equipment. Kent: We have been trying for a long time and we belive we require a network based solution. It is not easy to convince enterprises to buy MIP client. Hesham: What is the isue. Is it poltical or ? Henrik: This is not a host protocol. The customer for this is .. Vidya: Will the funcionality be the same as it would be with a normal MIP client Kent: This is for global mobility Alex: What is the packet type. Do we have an idea of what type it is Ajoy: There can be a FA in the illustration as well right. It will help if we clarify htis. Kent: yes Charlie: Any comments on the IPR's on this draft. Kent: We have a patent on this. Vijay: The correct way is to send a note to the IETF IPR disclosure page. draft-chowdhury-netmip4-00.txt presented by Kuntal -------------------------------------------------- Pete: whats the different between the two drafts? did the authors read each others drafts Kuntal: there are some subtle differences. Pete: Then there was some discussion on global and local mobility. One difference is about preconfigured SA's or the dynamic SA's Kuntal: don't understand the difference between local and global Kent: Global vs local mobility has different implications for security. Issue for global vs local is not discussed in either drafts. We are just focussing on the signalling. In wlan space, it is possible to configure SA's for range of MNs's. Right now we are just focussing on the signal flow. Hesham: The use case can have implications on security. High level question - Are we going to solve business problems? There are not technical protocol issues. Jari: We do technical work at IETF. Pete: We are not chartered for this. We will consider NETLMM Jari: I am worried about doing the same work in multiple places. NETLMM is considering PMIP as one solution. We can solve technical problems here. Not others. Kent: The charter of the MIP4 WG says we will deal with deployment issues. So thats the justification for this work. Gopal: This is not a business problem. There are many reasons why there is no MObile IP client software on the mobile node. This addresses this. Hesham: I don't agree that it is a deployment problem. Then the real problem seems to be that you cant install software on the client. In that case, do you need Mobile IP at all? draft-navali-ip6-over-netmip4-00.txt ------------------------------------ Pete: This has come before. Putting v6 addresses in v4 signalling Alex: this scenario makes no sense. The network supports DHCPv6, but not IPv6 and supports Proxy MIPv4? Kuntal: There could be cases Alex: If the access network has a DHCPv6 server and hands out IPv6 addresses, then the access network should be able to route the IPv6 address. Alex: NETLMM does IPv6 only according to the charter. Henrik: There are many opinions here. We need to discuss in the mailing list. Raj: Why do you assume the mobile node has IPv6, but no IPv4? Thats a wrong assumption Hesham: You have to lookup the differences between IPv6-capable, IPv6-enabled, IPv4-capable, etc... Vijay: Agrees with Raj. We shouldnt start work items based on the assumption that the MN will support IPv6 but not IPv4. NAI based home address ---------------------- draft-paulkandasamy-mobileip-nai-based-home-addres-01.txt Charlie: Disagrees that RFC 2794 is ambiguous. NAI is only an alternate identifier. not a request for address assignment Vijay: I dont see the ambiguity either. We need to work on motivation. Kent: We had questions when we implemented this. So thats why this work. Charlie: These are new extensions you are requested. If you need anything clarified in 3344bis, we can do it. Kent: The lifetime of the SA is not specified. We currently tie it to binding lifetime. Charlie: thats not a good idea Pete: when we go to 3957 we distribute the lifetime along with the nonces. Kent: We are not trying to add new functionality. There was a discussion on what indexes the SA when there is no home address Charlie: NAI is not mandatory. We can do authentication based on the SA present. You cannot have SA if home address assighnment is enabled. With the help of AAA, you can eastablish that. Henrik: When we implemented, there were some questions, but we figured out what to do. But would probably have been better if we had these clarifications. Charlie: the mobile node is supposed to have a longer a home address. the HA is not a DHCP server. Mobile IP is not a protocol where you keep constantly re-assigning the home address. Pete: Lets take it to the list. We dont have time for the preso on Generic Notification. Generic notification messages ----------------------------- draft-deng-mip4-generic-notification-message-01.txt No time for this. Henrik: how many people are interested in IPv6 over MIPv4? ? people raised hands. Vijay: We should have a discussion first before taking a vote. Henrik: I want to get a sense of the room. About 2 against and 10 in favor.