IETF-69 mip4 agenda Slides RFC3344bis Status Proxy Mobile IPv4 MIP4 MOBIKE optimizations RADIUS vs. Diameter MIP4 Application Impact on MIP4 Session Setup Multicast Broadcast with Mobile IPv4 Dual-stack Mobile IPv4 Agenda Mobility for IPv4 WG ======================================================================= WEDNESDAY, July 25, 2007 1510-1610 Afternoon Session II Adams ======================================================================= CHAIRS: Henrik Levkowetz Pete McCann AGENDA: 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 In Last Call - To IETF last call when dhc WG says WG last call complete draft-ietf-mip4-generic-notification-message Active - Please review and comment draft-ietf-mip4-nemo-v4-base Active - Please review and comment draft-ietf-mip4-nemov4-dynamic Active - Please review and comment draft-ietf-mip4-nemov4-fa Active - Please review and comment draft-ietf-mip4-rfc2006bis Active - Draft ready for last call (?) draft-ietf-mip4-rfc3344bis Active - Final final wg last last call 3344bis - draft 05 believed to be in good shape, forthcoming final edits before the 06 goes to the IESG. draft-ietf-mip4-udptunnel-mib Active - Please review and comment udptunnel-mib - accepted last time, no comments on this. Author believes there are still things to be done, please comment. If there are no comments, this will go to mib-doctor review. Adopted last time. Needs re view now. Kent Leung asked to review, but non-commital due to difficulty finding MIB reviewers. Henrik: Let's just send it to MIB doctor review draft-ietf-mip4-vpn-problem-solution Expired - Waiting for shepherd writeup vpn-problem-solution - waiting for shepherd writeup. Not happened yet, due to chair oversubscription. Will get prodded along in the next few months. Henrik to act on this one. IESG Processing: draft-ietf-mip4-gen-ext AD Evaluation - through last call from DHC WG. One comment in the DHC list, but as soon as this has been received we can move to IETF Lastcall. Pete did write-up on it. draft-ietf-mip4-mobike-connectivity IESG Evaluation - Waiting on draft-ietf-mip4-vpn-problem-solution IESG wants to discuss those two together. draft-ietf-mip4-radius-requirements IESG Evaluation - Discuss received, new document was submitted Discuss removed, progressing. RFC-Editor's Queue: draft-ietf-mip4-fmipv4 RFC Ed Queue Published since IETF 68: draft-ietf-mip4-message-string-ext RFC 4917 draft-ietf-mip4-reg-tunnel RFC 4857 draft-ietf-mobileip-lowlatency-handoffs-v4 RFC 4881 3. Mobile IPv4, Revised 5 min Charles Perkins draft-ietf-mip4-3344bis Note: document now converted to XML thanks to Vijay Issue: 2 MNs at same FA have the same IP addr but different NAI extensions. * Perhaps due to dynamic HoA assignment * FA already store NAI with registration records * New text to use the NAI to disambiguate records in this case -- Rewrote as few sentences to enable use of NAI to disambiguate recoreds if to mobile nodes have the same address. Vijay: draft standard or PS? Peter: to the mailing list Kuntal Chowdury: NAI can be used to disambiguate at the FA, but on data transfer what to do? * Tunnel and link layer info can help * Kent: this is control plane, but what kuntal mentioned is data plane for which the GRE key can help * Henrik: same HA, same IP address for two different MNs? * Pete: this has been specified by PP2 perhaps to have one single HA box to handle different overlapping address spaces * George Tsirstis: in this case, have them use the GRE key, but the base spec need not contemplate this case * Henrik: then they should fix this themselves * Pete: perhaps, reverse tunneling does assume that MNs at a given HA always have different IP addresses * Kuntal: yes one HA handling several address spaces * NAI can be used in control plane * Cannot be used in data plane * Suggestion: insert a reference to the GRE key draft * Samita: if this is a valid configuration, how does the HA decide which tunnel to use? * Charlie: let's not add a dependability on an unfinished draft from another SDO. * George: yes, let's make this limitation clear here in this spec * The GRE spec can address that case * Henrik: what he said. * Kuntal: but make this limitation explicit * Gab: what he said and what henrik said. Pete/Charles: Send Text. 4. Proxy Mobile IPv4 10 min Kent Leung draft-leung-mip4-proxy-mode Presented at spring IETF 06. Merge of two drafts that were outstanding then. And eliminated some overlaps in the process. Purpose of Draft: Document based PMIPv4 spec; Document needs of WiMAX and 3GPP2, including use models. We would like to establishing the bask function for interop, and allow for the other SDO's to use this base. Also tries to organize draft better, however this still needs some work. Gab: suggest making the liaison statements explicit (e.g., in the references section) Kent - we don't Gab: - we should, and this makes clear what the statements. Kent - also need to better engage the other SDO's and this is progressing, so sync is improving. Jari: and make the goal clear: * Just submitting for informational so full IETF review process is not required? Kent: might not be a formal liaison, but let's resolve this outside this forum and get back to MIPO4 on it Alper: we'll review this in wimax forum, and a liaison can follow Pete: I'd like to have that in before submitting a document as "wimax and PP2" document into IETF George: any differences between wimax and pp2 versions of the protocol? Kent: more use model differences Anand: Is the PP2 stuff available in any PP2 spec? Kuntal: there is some baseline in a PP2 WG, they will use this for next gen UMB Anand: Please add those references Kent: we can do that. Version 3 changes * NETLMM terminology (MN, MAG, LMA) * Securing reg msg * MN-HA auth ext * FA-HA auth ext * Ipsec * Extensions * Pmipv4 mode indicator * Per-node authentication method intead of per auth extension * Access type indicator * Devide ID * Error codes * Unsupported * Unallowed Next Step * Expert review * Ensure base spec is sufficient * Satisfy needs of wimax and PP2 * Next rev: end of August 5. Mobike Optimizations 5 min Vijay Devarapalli draft-meghana-mip4-mobike-optimizations MIP4-MOBIKE interworking with IESG * MIP4 over Ipsec tunnel * Ipsec remote IP addr uses as colocated CoA for MIP4 registration * Inside trusted network, MIP4 as usual Disadvantages * Tunneling overhead when MN is outside trusted network * FA CoA not addressed FA co-located with VPN GW * Ipsec tunnel MN-VPN GW is a single hop p-p link between MN-FA * FA agent advertisement sent over this link HA co-located with VPN GW * Co-locate HA * Ipsec remote IP addr == MIP4 HoA * When attached to the VPN GW, the MN is at home * HA agent advert sent over the Ipsec tunnel Pete - let's discuss on the mailing list and see where to go 6. Diameter MIP4 Performance 5 min Ahmad Muhanna draft-muhanna-diameter-mip4-performance Radius versus diameter impact on mip4 session * Radius is not integrated, so FA does both AAA traffic (Access Req & Access Accept) and MIP Reg traffic (RRQ, RRP) * It's having visibility into the process in finer granularity allows the FA to now which traffic to re-send if a new RRQ arrives, so potential savings are possible * Diameter is integrated so AMR/AMA does not allow it to decide whether it makes sense to re-issue it completely, so it ends up doing so if there is another RRQ * Potentially may hurt performance Suggest using diameter in a RADIUS model Next steps: worth pursuing? can we use this draft as the problem statement doc? Alper: agree that aligning the call flows with RADIUS is a good thing as this is what is being specified in wimax, for example * Support this independently of the performance issue mentioned in the presentation Pete: please send a succint problem statement to the list as this was not very clear from the draft. Henrik: perhaps to pursue with DIME (not entirely a MIP4 issue) 7. Selective use of encapsulated delivery style 5 min Samita Chakrabarti draft-chakrabarti-mip4-mcbc 3024 says that if one wishes to support MC/BC then not just that traffic but *all* traffic has to be encapsulated (including unicast) Kent - to clarify, this isn't for all, but it is up to the MN to pick. The MN can selectively pick. Samita - in overview, section 2, there is a line saying that if encapsulation style is used, then it must be used by all. Kent - if you register with the encaps stype, up to MN. Ahmad - I disagree with Kent. -- discussion scribe didn't quite catch -- Kent - The key thing here is the issue here is for mcast and bcast, it must be encapsulated. Trying here to say that there should be a better way for p2p links. I support this draft. Pete - let's take this to the list, we're short on time. Samita - 2 more slides. Pete - okay New MBED extension (multi-broadcast encapsulating delivery extension) * Advertised by FA * Negotiated/specified by MN in RRQ Potential for link-layer assisted delivery as well * For further optimization * To distinguish between traffic meant to be consumed/process "locally" versus reverse tunneled Kent: backward compatibility? Samita - bit field value, if set to 1, backward compatible. Kent - this is a new type, how do you deal with that? Samita - two different extensions. Kent - if both styles are in the registration request, how is that dealt with? Ahmad: it's in the RRQ, so the client can negotiate whatever it wants Samita - text says "only the first one is accepted" Kent - ? Samita - we can change this. Ahmad - client is sending RRQ, if client wants to negotiate old style (this one is better, not sure why you'd want that), but it could be enabled. Henrik: suggest that if both the new and old are in the RRQ, then it's an error Ahmad and Kent: sounds good Samita: adopt this? Henrik: will consult with ADs and get back to the group on this 8. Dual Stack MIPv4 draft-ietf-mip4-dsmipv4 5 min George Tsirtsis In LC (review by Alex primarily) Type of IPv6 in IPv4 encapsulation? * Will point to RFC4213 when IPv6 is tunneled directly to CoA * When tunneled to HoA then tunneling to MNs Ipv HoA uses 4213, then to MNs CoA per MIP4 negotiated tunneling (IPinIP, GRE, etc) Security * HA's and FA's should check that src addr is derived from registered IPv6 prefixes v03 will be published shortly after IETF. Kent - I'll send some comments on list, but I think this is in good shape and well written.