Thanks to the following people for taking minutes: Acee Lindem Marco Liebsch George Tsirtsis TUESDAY, December 4, 2007 1850-1950 Afternoon Session IV Salon A CHAIRS: Henrik Levkowetz Pete McCann 1. Preliminaries 10 min Chairs - Blue sheets - Note takers - Jabber scribe - Agenda bashing 2. Document Status 15 min Chairs WG Documents: draft-ietf-mip4-dsmipv4 ->to IESG when writeup done draft-ietf-mip4-generic-notification-message ->LC after meeting draft-ietf-mip4-nemov4-dynamic draft-ietf-mip4-nemov4-fa ->updated, need review and comments draft-ietf-mip4-rfc2006bis ->ready for LC draft-ietf-mip4-rfc3344bis ->writeup after meeting draft-ietf-mip4-udptunnel-mib ->review and comments solicited. IESG Processing: draft-ietf-mip4-gen-ext AD Followup draft-ietf-mip4-mobike-connectivity IESG Evaluation draft-ietf-mip4-nemo-v4-base AD Evaluation draft-ietf-mip4-vpn-problem-solution IESG - Revised ID needed ->Comments from IESG need to be addressed Jari - Comments from IESG need to be addressed to get it approved. There is a change suggested that needs to be incorporated. It will be discussed on the list. ->Pete: Propagate AD comments to the list and get comments. Vijay Devarapalli - MOBIKE Connectivity comments addressed. Published since IETF 69: draft-ietf-mip4-fmipv4 RFC 4988 draft-ietf-mip4-radius-requirements RFC 5030 3. Home Agent assisted Route Optimization 15 min Antti draft-makela-mip4-nemo-haaro Home Agent assisted Route Optimization between Mobile IPv4 Networks. Motivation, background and a technical overview. Background: technological enabler and motivator Extension for Mobile Router to indicate route optimization caps Route optimization prefix advertisement extension - Needed when mobile routers are multi-homed. - Route optimization between MRs connected to single HA. - Gives Mobile Routers awareness other networks registered. - HA information is assumed trustworthy - Return routability procedure used to verify path on router knowing about the other prefix - NAT/Firewall considerations added. ->Charlie Perkins: AAA mentioned but not involved in the protocol extensions ->Antti: HA makes use of credential of MR. Cannot assume that MR has access to AAA Charlie - Optional verification mobile router going back to the HA, when is it needed? Antti - Needed for /32 addresses. MR might have the HoA from management. ->George T.: Registration reply includes all other nodes. Say 1000 nodes do that, not a large number ->Antti: Ok, scalability issues. HA may choose some priorization. No idea how good it scales. ->George: If you send everything in Reg Reply, that seems difficult scalability wise. Sri Gundavelli - Question on allocation of mobile router prefix - is it on the home agent or some place else in the network given the dynamic nature of the assigment? Henrik - Reply contains exactly those prefixes allocated. Sri - Registrations come and go. Prefix information will be stale. Kent Leung - Agrees there could be a problem with mobile routers coming and going and prefixes being reallocated. Kent - Implies mobile router prefix binding management. Antti - Mobile Router might not be mobile - just unreliable cheap networks. Kent - NHRP could possibly solve this problem in a simpler manner. Alex Petrescu - Likes presentation since it offers business case and solution. There can be a method to address George's question by requesting. Antti - Was envisioning static prioritization of the prefixes. Alex - Business case - works when a single Home Agent owns all the mobile routers. Antti - Possible to extend to multiple Home Agents. Henrik - Kent has a good point that there might be other solutions. Return Routability test is not needed when both routers share the Home Agent. Antti - Allows extension to prefixes managed by multiple Home Agent. Henrik - Remove for now. Antti - Ok Hans Sjostrand - Why can't a VPN be used to solve this problem? Antti - Hard to provision while mobile IP has it build in. Hans - Black holes will occur. Antti - When hand-over occurs, re-registration is required with ALL correspondent node? ->Cheng-hua: Nice approach, but: HA sends back prefix in acknowledgement. Better: When HA received data from MR, then send... ->Antti: Traffic is assumed bi-directional. Could do routing updates ->Cheng-hua: RFC 4881, maybe you have a look. (note taker: Sorry, missed the point here..) ->Henrik: MIP4 plate is full - cannot make this a new WG document at this IETF. For now keep this in back-burner. 4. Host Configuration -- Options vs. DHCP INFORM 15 min Ralph draft-ietf-mip4-gen-ext It has been suggested that the DHCP INFORM message is so simple, and straightforward to use that the gen-ext draft may be unnecessary. Exploration of the issues together with a DHCP expert. DHCP inform brief description and discussion 2 slides used by client to obtain other configuration information, does not perform address assignment. DHCP Server need not maintain state. Send/Receive characteristics similar to DHCP request DHCP Ack is sent in response. discussion: Can DHCPINFORM be unicast through tunnel? How can client learn DHCP server address? Vijay Devarapalli - Home agent could just respond rather than implementing the DHCP relay. Henrik Levkowetz - DHCP relay is known while proxy DHCP agent is new invention. Alex - What kind of information would DHCP Inform be used for? Pete McCann - DNS Servers, other non-address information. Alex - Very useful. What is the response? Ralph - DHCP Ack Kent - What if Mobile client doesn't have DHCP? How is DHCP server adddress learned out-of-band? Ralph - Learning DHCP server is beyond scope of document. Henrik - Kent's first question - DHCP options sent in MIP message is the alternative. Don't see that DHCP client functionality can be an issue if you must implement it in MIP anyway. Ralph - Option implementation is the hard part anyway of DHCP. Pete - Configuration options may come from the visited network. How would this work? Hans - You can get broadcast DHCP Inform/Ack to DHCP server. MIP signaling could be used as well and provides transactional safety of registration sequence. Ralph - Home Agent may know better what option the mobile clients needed. For client enabled application, new options may be obtained. Pete - Problem with broadcast reverse tunneled by Foreign Agent. Hans- Reverse tunneling should be fixed. Kent - Need an alternative to encapsulation delivery style for reverse tunneling. Today we need to a solution independent of this document. Henrik - A draft exists to remove the reverse tunneling and encapsulating delivery style short comings. Hans - Implementations have solved the problem. DHCP Inform or extended MIP4 registration? Why not add to mobile IP? Vijay - Not comfortable with mandating DHCP as the only mechanism for updating configuration information. Pete/Henrik - Need to guard against providing multiple ways of configuration. Jari Arkko - AD viewpoint is to choose one method if you can. Will this be done on every handover? Ralph - No Charlie - DHCP Inform sent to DHCP Server? Ralph - Yes - it will get there eventually, possibly via a relay. Charlie - Create the fewest number of packet format? Henrik - DHCP exists - why create a new mechanism? Charlie - Non-DHCP client sending DHCP Inform to DHCP server? Ralph - Not necessary. Henrik - There are DHCP clients of varying functionality. Charlie - Would contend that this is not an existing mechanism due to the roles and packet flows. Not best decision point. Jari: MIPv4 specific viewpoint. Do these things with other protocols. For discovery you have nowadays mechanisms available. Why solve in MIPv4? That's the question. MY advice is to do the DHCP based approach. Kent: Agree, but not sure DHCP Inform addresses all the cases satifactorily. Henrik - Kent's is the best argument. If we can't solve the problem, we need an alternate mechanism. Mobile IPv4 Extension Hum: Low Hum DHCP Inform Hum: Medium Low Hum DHCP Inform is preferred. Kent - Technical evaluation is needed saying how it would be used for all the applicable cases. ->Kent: Suggest for DHCPINFORM preferences, write a draft how that works. ->Henrik: Writing a draft makes sense. Take to the list to clarify. Not a draft, but text is necessary. ->Pete: Done. See you Thu night. THURSDAY, December 6, 2007 1510-1610 Afternoon Session II Oak Agenda (Thursday): 5. Preliminaries 10 min Chairs - Blue sheets - Note takers - Jabber scribe - Agenda bashing 6. MIP4 Service Selection 10 min Jouni draft-korhonen-mip4-service - Need to distinguish between multiple services - These are partioned in service domains - MIP4 Service Selection Extension - Could be used for things such as QOS Pete: How many people have read the draft (a few/not many) Hans: It is a good idea we should take it on Sri: Agree, we should take it on Pete: We need to recharter for this Jari/Pete: yes, we should consider it at that time 7. Bulk Revocations 10 min Acee draft-acee-mip4-bulk-revocation Sri: This was discussed in the past. Not sure why it was then forwarded. How do you use the "tunnel type"? Acee:So you can revoke all bindings using specific tunneling mechanism, but it is not easy to find a good use case Sri: With the home address range? When addresses overlap how is this handled? Acee: Not sure, have to think about this Henrik: The GRE-key proposal is to be discussed later which should help. When this was discussed again there was some activity for a while but then the author was too busy and so there was no one to handle this. BTW, Prefix Length is defined as 8bits, 5 would do. Acee: It would be better to go down to 5 so that we free some bits. Will think about this. Pete: the draft will be considered during rechartering 8. MIPv4 Extension for GRE Key Exchange. 10 min Parviz draft-yegani-gre-key-extension - Used for overlapping private addresses between the same FA and HA. - How do agents know how to handle this unambiguously? - Standard option for a given MN's flow - (CoA, HoA, and HA addr) Henrik: What is the scenario? you want to handle the occasional collision when the CoA and HoA are the same? Sri: Generally two MNs can have the same HoA and find themselves under the same FA Hans Sjostrand - tuple is the identifier for binding. For example, it hits the MIB. Changing the basic identifier would impact all of MIP4. Sri - We will need one more qualifier. Sri - Draft will be changed to not mandate new extension for GRE key when GRE is used. Ahmad: FA can also request GRE negotiation? Sri: Yes Ahmad: does it require FA-HA authentication Sri: it is not mandated in the draft. Why should it be required? Ahmad - Since it is an option added by the FA. Henrik - Pointed out error in slide related to IANA assignment of key. Henrik: Is this something to be considered in rechartering? Sri: Yes, Henrik: I am worried about this breaking the MIB Sri: needs additional parameters in the MIB table. MIB can be extended. Hans - Does destroy MIB. This may be one just one example. Sees business case. Henrik: More correct statement is that we need to extend the MIB i.e., change the MIB RFC Ahmad - Does FA still set the G bit? Sri - Based on both G bit and extension. FA local policy determines if extension is added. George Tsirtsis - May need to check for a liason statement. He seems to think it may have been3GPP2. Pete - May be done today using vendor specific extensions in 3GPP2. 9. A Diameter MIPv4 application for Key Distribution 10 min Pete - RFC 4004 - Diameter flow from MN->FA->HAAA->HA - Takes time to authenticate and MN may retry. - Designed to work with RFC 3957 - WiMAX and 3GPP2 want an update. - Requires new DIAMETER work to support retrieval of keys by HA. Vijay: This does not obsolete 4004. This is just to add the ability to bootstrap this from EAP Pete: Yes Ahmad: Probably by next meeting we eill have a draft describing this. Where should the discussion be held? Pete: probably on MIPv4 to begin with. Requirements and use cases done here. Handed off to DIME 10. PMIPv4 Status Update 5 min Kent draft-leung-mip4-proxy-mode Pete: This is not a WG item, just trying to get feedback from the group Acee: Is this an Informational then? Sri: Yes - Presented on behalf of authors. - Reviewed by WiMAX, 3GPP2, and IETF MIP4 - Aligned closely to WiMAX NWG - Aligned with WiMAX DHCP - Need Feedback. Henrik - Meeting close. Encourages people to go throught the document status and minutes noting documents that need review and mailing group comments.