Minutes of: Mobility for IPv6 (mip6) WG At: IETF66 July 13, 2006 (Montreal) Chairs: Hesham Soliman (hsoliman@qualcomm.com) Vijay Devarapalli (vijay.devarapalli@azairenet.com) Credit for these minutes: 1. Gabor Bajko (gabor.bajko@nokia.com) 2. Brian Haley (brian.haley@hp.com) Vijay Devarapalli and Hesham Soliman chairing the meeting on behalf of Basavaraj Patil and Gopal Dommety 1. WG document status ---------------------- - 3 RFCs published RFC 4487, 4449, 4295 - 2 in RFC Ed queue (bootstrapping and mip6 api extensions) - 2 in Last Call - 2 in AD evaluation 2. Charter Discussion --------------------- Jari - Proposed content for the rechartering. Scope: to align the charter description with the work the wg is already doing. Taking on board new work not necessarily the intention. Gerardo - Should bootstrapping cover auth option also? Jari - work on bootstrapping with IPsec for the time being, consider 4285 only if 3gpp wants that. Petrescu - For dual stack, separate problem statement preferred for mipv6 wg. George - Have a common problem statement doc. Hesham - Good to have a problem statement document, but not necessary for the solution development. Vijay - The problem description in the DS-MIPv6 solution document is sufficient for DS-MIPv6. A separate problem statement is not needed. Jari: Some adjustment to the charter needed. Will change charter monthly if that's what we want 3. DHCP Option for Home Information Discovery in MIPv6 ------------------------------------------------------- I-D: I-D: draft-jang-mip6-hiopt-00.txt Hesham - has been discussed on the list, does it need to be standardised at all? Petrescu - networks are identified by other means, not the proposed HNid Hesham - usage of HNid is common practice Alper - This doc is next step after the framework doc. Gerardo - Objects to a standalone document Alper - this doc should be standalone. It can support static configuration. Similar to how RFC 2132 defines a DHCP option for MIPv4 home agent. Vijay - There was never an intention to define a framework document, just one solution document for the integrated scenario based on DHCP. Hesham - lets take it to the mailing list. Gerardo - has been discussed for more than 6 months. we need to decide. Vijay & Gerardo - Scrap the current working document if thats not needed at all. draft-jang can define how to use DHCP for MIP6 bootstrapping. Hesham - solution is agreeable, but no agreement on document organization. Work offline and send something to the MIP6 mailing list 4. Problem statement for Dual Stack MIP --------------------------------------- I-D: draft-ietf-mip6-dsmip-problem-02.txt No discussion 5. Dual Stack MIPv6 ------------------- I-D: draft-ietf-mip6-nemo-v4traversal-01.txt Petrescu - why do we need keep-alive? Hesham - to keep the NAT bindings alive Petrescu - there are NATs which do not keep mappings even in presence of keep alives Henrik - questions the statement. does not believe there are NATs like that. Alex - have seen them Henrik - we need product name and model number sent to the list to verify Alex's statement Hesham - scenario: dynamic detection of NAT in the HA's domain: there might be IPRs Vijay - nice to have, not necessary feature. Could be in a separate doc. Hesham - should the feature be added or not? Alex - The problem statement does not talk about this scenario. George - not necessary in the DS-MIPv6 solution document Henrik - IPR bothers him. if this will limit open source development of this draft, then we can't have it Leung - optional feature, it does not hurt having it Vijay - It would be hard to distinguish which part of the spec has IPR claims and which does not. IPR disclosure statements don't specify that. Sri: it does not make sense to not standardise it because of IPR. NEMO standardised IPRed solutions. Vijay - Each IPR decision needs to be taken separately. Precendent is not useful. Ruiji: relax 3775 for the NAT case (req to use altCoA when ESP is used). Vijay: look at it as updating 3775 for NAT case 6. HA Reliability ------------------ I-D: draft-ietf-mip6-hareliability-00.txt ? - Don't think we can pre-establish multiple security associations as specified Ryuji - this is done at bootstrapping time Petrescu - Why didn't we extend BRR instead of creating HA switch? Brian - We could have, but didn't Hesham - Why do we have switchover message? Vijay - It's sent from the standby HA to become active Bob Hinden - Should be very careful with deteting HA failures and switching home agents. it is a hard problem. see VRRP for more details. Brian Haley - There are 2 things fault detection and state transfer. Fault detection is not specific to this WG, they are IETF-wide so it would be good to define them separately for that reason Kent - routers already have hello beacons for a lot of things, we're adding one more thing here. should we make this more generic and maybe separate it out? 7. Experimental and Vendor-specific options and messages --------------------------------------------------------- I-D: draft-devarapalli-mip6-vsm-00.txt draft-devarapalli-mip6-experimental-messages-00.txt Alex - Why do we need both? Vijay - Vendor-specific could be deployed, experimental shouldn't. They are for separate purposes. Henrik and Kent against vendor-specific message, ok with vendor specific mobility option 8. Bootstrapping for RFC 4285 ------------------------------ I-D: draft-devarapalli-mip6-authprotocol-bootstrap-00.txt Hesham - Will this be informational like 4285? Vijay - Yes Vijay - What should the WG do? ? - Not currently in charter, if we do it it's informational, will add it to the charter discussion 9. AAA goals status ------------------- I-D: draft-ietf-mip6-aaa-ha-goals-02.txt Gerardi - should we consider requirements for 4285 bootstrapping? no comments 10. Scenario analysis and problem statement of the dual-stack mobile entity roaming in the ipv4 and ipv6 network -------------------------------------------------------------------------- I-D: draft-wan-mip6-nemo-dsanalysis-00.txt George - need to explain the problems better Henrik - doesn't see what the problem is either; believes dsmip will solve this Henrik- if the home network doesn't support ipv4, but you need to use it, what do you do? Why can't you just deploy ipv4 there to solve it? That is the simplest solution. Same with ipv6. Hesham - what are you going to do with this ipv4 address if the link doesn't support it? Tunnel it somewhere? DSMIPv6 solves this today. Hesham - it's not clear all the scenarios are problems George - need to better define the protocol and the scenario it will be used in 11. MIPv6 Firewall issues ------------------------- I-D: draft-bajko-mip6-rrtfw-00.txt - Some work done in NSIS WG based on NSLP - Gabor presented some slides on modifying return routability messages to make Mobile IPv6 friendly to firewalls. 12. Next steps --------------- - revised charter - consider new wg docs based on charter