Two active RG documents: - L2 abstractions for L3 handovers - underwent LC - location privacy solutions for mipv6 - need RG input - ro enhancement document in IESG New documents(?): - mobility and multicast PS (received a couple of reviews already) - policy and mobility (new work originating from montreal meeting) Gap analysis between draft-irtf-l2-abstractions Two reviews received: Christian Vogt and Jukka TJ Manner. Found issues and questions were addressed and proposals for corrections presented. Quite a few clarifications still needed. Although l2-abs and 802.21 are quite similar there are some architectureal differences: - l2-abs doesn't use a shim layer between L2 and L3 - l2-abs exchanges information between any layers - l2-abs reqiures modifications to the mobile node only Questions to RG: - Interaction naming: will be changed to B (see slides) Q: Is this complementing or replacing 802.21? A: No for both. This is independent proposal. Q: Where the L2 information is redceived? From media driver? How it is different from having APIs? What is the abstraction? A: the abstraction is to have same l2 primitives independent of the l2 media. Q: What is the relation between l2-abs and 802.21? A(Raj): The work done in mobopts is independent of 802.21. We do l2 abstractions to enable mobility. The fact that 802.21 is doing similar work is irrelevant to this work. What is going on outside IETF is irrelevat to this discussion. There were some open issues the presenter wanted the RG to help with. He was adviced to take the questions to the mailing list with some justification added to the solution proposals. Q: What is the end goal for this work. A: One of the goals is to enable fast handovers. We are trying to specify l inklayer triggers to enable faster handovers. Multicast Mobility in MIPv6: PS update Several reviews received for version 00. First reviews received also for the 01 version. The multicast mobility problem can be divided into multicast receiver and multicast source problems. The receiver problems is to ensure multicast reception in visited networks for a MN. Q(Charlie): in seamoby multicast state was a context that could be moved from AR to AR. This results in almost zero lost. There are several approaches that can be taken to solve the receiver part:remote subscription, bi-directional tunneling via HA, agent based Q: What is the scenario in which a MN is the source of multicast traffic. Muticast receiver part of the problem is more reasonable. A: If a streaming server is mobile, this is applicable. Q: If ad-hoc networks is where the source mobility would be used have the manet things been looked at and how e.g. HMIP applies in these environments. A: The manet part has not been investigated. Policy and Mobility (Jouni Korhonen): Motivation is that it has not been considered how the policies defined by the operator may affect the user's mobility experience. Policies may govern: the services allowed for the user, access network the user is allowed to access, QoS, restriction to certain mobility protocols. This presentation was done because of an action item from IETF66 to document the problems encountered in applying IP mobility due to policy constraints. An I-D is under process. Next steps is to create an I-D that describes the problems encountered when applying IP mobility protocols to networks where operator defined policies and the resulting constratins exists. Topics to be covered: policies in operator controlled environment, case study 3GPP policy & charging control arch., identified issues in integrating IP mobility and policies. If the providers are different for the domains there needs to be an interface for roaming. MIPv6 Location Privacy Solutions: PS is in mip6 wg almost completed so it is time to look into to solution space. Pseudo HoA: needs to be secure, routable, dynamic. SPI needs to be changed for MN and HA by incrementing it by one. Q(Vijay): If you want to hide HoA you can use ESP in tunnel mode. Tunnel mode can be used all the time. No further comments. MIPv6 CN-targeted location and privacy and optimized routing: Problems 1) disclosing the location to CNs 2) disclosing the location to eavesdroppers.This draft addresses only 1) So how to achieve CN-targetted location privacy and use RO at the same time. Approach 1: RO with pseudo HoA. MN hides real HoA. Only works for MN initiated sessions. Location privacy is compromised if CN can figure out MN's identity on higher layers. Q(Raj): Are you really trying to hide the HoA or CoA. A: These are just what are the known alternatives. The proposal comes a bit later in the presentation. Approach 2: MN reverse tunnels to local HA Proposed idea: MN reverse tunnels to HA that is preferrably located close to CN or close to the path between MN and CN. This optimized Routing Home Agent (ORHA) is used for optimized communication. Open issues: how to discover ORHA, Q(Charlie): the ORHA knows the real HoA. What is really gained since the ORHA and the CN are probably hosted by the same domain. Q(Vijay): Concern about security credentials since the ORHA is not in the same domain as the actual HA. Roaming relationships needed between HA and ORHAs. Q: This is not applicable to all CNs. Only the ones in proximity of an ORHA. Q: Not a very practical solution. From deployment point of view this looks difficult. Q(Raj): There are a lot of assumptions. This is one option but surely needs more work. Mobopts is not that concerned about deployment. Media Independent pre-authentication and implementation framework and implementation drafts exists. Handoff delays exists at several layers L2, L3, binding update The challenge is even greater when moving between heterogenous networks. MPA is a authentication and authorization scheme performed before establishing L2 connectivity. It consists of 3 phases 1) pre-auth 2) pre-conf 3)proactive handover Uses PANA for preauthentication. The preauth part in in the HOKEY charter.