DMM Working Group CJ. Bernardos Internet-Draft UC3M Intended status: Standards Track JC. Zuniga Expires: September 15, 2016 InterDigital March 14, 2016 PMIPv6-based distributed anchoring draft-bernardos-dmm-distributed-anchoring-07 Abstract Distributed Mobility Management solutions allow for setting up networks so that traffic is distributed in an optimal way and does not rely on centralized deployed anchors to provide IP mobility support. There are many different approaches to address Distributed Mobility Management, as for example extending network-based mobility protocols (like Proxy Mobile IPv6), or client-based mobility protocols (as Mobile IPv6), among others. This document follows the former approach, and proposes a solution based on Proxy Mobile IPv6 in which mobility sessions are anchored at the last IP hop router (called distributed gateway). The distributed gateway is an enhanced access router which is also able to operate as local mobility anchor or mobility access gateway, on a per prefix basis. The draft focuses on the required extensions to effectively support simultaneously anchoring several flows at different distributed gateways. This draft introduces the concept of distributed logical interface (at the distributed gateway), which is a software construct that allows to easily hide the change of anchor from the mobile node. Additionally, the draft describes how to provide session continuity in inter-domain scenarios in which dynamic tunneling or signaling between distributed gateways from different operators is not allowed. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Bernardos & Zuniga Expires September 15, 2016 [Page 1] Internet-Draft PMIPv6 distributed anchoring March 2016 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 15, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution's overview . . . . . . . . . . . . . . . . . . . . . 5 4. Simultaneous anchoring of multiple flows (single operator) . 7 4.1. The Distributed Logical Interface (DLIF) concept . . . . 7 4.2. D-GW protocol operation . . . . . . . . . . . . . . . . . 10 4.3. Message format . . . . . . . . . . . . . . . . . . . . . 14 4.3.1. Proxy Binding Update . . . . . . . . . . . . . . . . 14 4.3.2. Proxy Binding Acknowledgment . . . . . . . . . . . . 14 4.3.3. Anchored Prefix Option . . . . . . . . . . . . . . . 15 4.3.4. Local Prefix Option . . . . . . . . . . . . . . . . . 16 4.3.5. DLIF Link-local Address Option . . . . . . . . . . . 17 4.3.6. DLIF Link-layer Address Option . . . . . . . . . . . 18 5. Simultaneous anchoring of multiple flows (multiple operators) 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 22 Bernardos & Zuniga Expires September 15, 2016 [Page 2] Internet-Draft PMIPv6 distributed anchoring March 2016 Appendix A. Comparison with Requirement document . . . . . . . . 22 A.1. Distributed mobility management . . . . . . . . . . . . . 22 A.2. Bypassable network-layer mobility support for each application session . . . . . . . . . . . 23 A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 23 A.4. Existing mobility protocols . . . . . . . . . . . . . . . 23 A.5. Coexistence with deployed networks/hosts and operability across different networks . . . . . . . . . . . . . . . . 24 A.6. Operation and management considerations . . . . . . . . . 24 A.7. Security considerations . . . . . . . . . . . . . . . . . 24 A.8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Implementation experience . . . . . . . . . . . . . 25 Appendix C. Public demonstrations . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction The Distributed Mobility Management (DMM) paradigm aims at minimizing the impact of currently standardized mobility management solutions, which are centralized (at least to a considerable extent). Centralized mobility solutions, such as Mobile IPv6 or the different macro-level mobility management solutions of 3GPP EPS, base their operation on the existence of a central entity (e.g., HA, LMA, PGW or GGSN) that anchors the IP address used by the mobile node and is in charge of coordinating the mobility management (MM) (sometimes helped by a third entity like the MME or the HSS). This central anchor point is in charge of tracking the location of the mobile and redirecting its traffic towards its current topological location. While this way of addressing mobility management has been fully developed by the Mobile IP protocol family and its many extensions, there are also several limitations that have been identified [RFC7333]. Among them, we can just highlight sub-optimal routing, scalability problems (in the network and in the centralized anchor) and reliability [RFC7333]. Several DMM-based approaches are being proposed and explored now [RFC7429], [commag.dmm-standards]. One of them is based on extending network-based mobility protocols (such as Proxy Mobile IPv6 [RFC5213] or GTP) to operate in distributed fashion. This document proposes a solution that falls in this category, defining a new logical entity, called Distributed Gateway (D-GW) which basically encompasses the functionalities of plain IPv6 access router, MAG and LMA, on a per- IPv6 prefix basis. The main contribution of this draft is the definition of the mechanisms required to support the operation of such a network-based mobility solution when several flows are simultaneously anchored at different D-GWs, by introducing the concept of Distributed Logical Interface (DLIF). The document also Bernardos & Zuniga Expires September 15, 2016 [Page 3] Internet-Draft PMIPv6 distributed anchoring March 2016 defines the required PMIPv6 signaling extensions. Last, but not least, the solution is also extended to provide session continuity across different domains. 2. Terminology The following terms used in this document are defined in the Proxy Mobile IPv6 specification [RFC5213]: Local Mobility Anchor (LMA) Mobile Access Gateway (MAG) Mobile Node (MN) Binding Cache Entry (BCE) Proxy Care-of Address (P-CoA) Proxy Binding Update (PBU) Proxy Binding Acknowledgment (PBA) The following terms are defined and/or used in this document: D-GW (Distributed Gateway). First IP hop router used by the mobile node. It provides an IPv6 prefix (topologically anchored at the D-GW) to each attaching mobile node. Anchoring D-GW. A previously visited D-GW anchoring an IPv6 prefix which is still used by a mobile node. Serving D-GW. The D-GW the MN is currently attached to. DLIF (Distributed Logical Interface). It is a logical interface at the IP stack of the D-GW. For each active prefix used by the mobile node, the serving D-GW has a DLIF configured (associated to the anchoring D-GW). In this way, a serving D-GW exposes itself towards each MN as multiple routers, one per active anchoring D-GW. HSS (Home Subscriber Server). In a 3GPP architecture, it is the master user database that contains the subscription-related information (subscriber profiles), performs authentication and authorization of the user, and can provide information about the subscriber's location and IP information. Bernardos & Zuniga Expires September 15, 2016 [Page 4] Internet-Draft PMIPv6 distributed anchoring March 2016 3. Solution's overview A new logical network entity, called Distributed Gateway (D-GW) is introduced at the edge of the network, close to the MN. It implements the functionality of a plain IPv6 access router (AR), a mobile access gateway (MAG) and a local mobility anchor (LMA), on a per-MN and per-IPv6-prefix, as described later. The solution basically extends Proxy Mobile IPv6 [RFC5213] to behave in a distributed fashion, similarly as what has been proposed in [I-D.seite-dmm-dma] and [I-D.bernardos-dmm-pmip]. This is achieved by the D-GW logically behaving as a distributed mobility anchor, which comprises the following: o When a mobile node attaches to a D-GW (initial attachment or handover), the D-GW provides an IPv6 prefix to the MN, acting as a regular IPv6 router (with the only difference that the delegated prefix is only assigned to one single MN, not being shared with any other node). The D-GW that the mobile node is currently attached to is called "serving D-GW". o When a mobile node performs a handover, it attaches to a new D-GW and configures a new IPv6 address out of the prefix provided and anchored by the new serving D-GW. As before, the serving D-GW behaves as a plain IPv6 router for that particular MN and the delegated (locally anchored) prefix. If the MN has active traffic using addresses anchored by other D-GWs (which are called "anchoring D-GWs") or it just needs to keep the reachability of these addresses, the current serving D-GW also acts as MAG, by sending the required proxy binding update (PBU) to the corresponding anchoring D-GWs. The anchoring D-GWs therefore behave as LMA for this particular MN and the IPv6 prefixes they are anchoring, replying with a PBA. o Once the PBU/PBA signaling is completed, a bidirectional tunnel is established between the serving D-GW and the anchoring D-GW (one per D-GW anchoring an active prefix used by the MN). These tunnels are used to provide IP address continuity to prefixes that are not anchored at the serving D-GW. o The means for a serving D-GW to obtain the information about the prefixes that a locally attached mobile node wants to keep reachable, and the associated anchoring D-GWs are out of the scope of this draft. Among the possible mechanisms that can be used to let the D-GW know about the prefixes that should be kept reachable, we can cite for instance layer-2 triggers/signaling. Regarding the mapping of IPv6 prefixes to anchoring D-GWs, there might be either fully distributed mechanisms in place, or the Bernardos & Zuniga Expires September 15, 2016 [Page 5] Internet-Draft PMIPv6 distributed anchoring March 2016 information can be maintained in a centralized repository (e.g., in the HSS, using a centralized LMA [I-D.bernardos-dmm-pmip], etc.). The basic operation of the solution is shown with an example in Figure 1. MN1 attaches to D-GW1 (thus becoming its serving D-GW) and configures an IPv6 address (prefA::MN1) out of a prefix locally anchored at D-GW1 (prefA::/64). At this point, MN1 can communicate with any correspondent node of the Internet, being the traffic anchored at D-GW1. If later on MN1 moves to D-GW2, a new IPv6 address (PrefB::MN1) is configured by the mobile node, this time out of prefB::/64, which is anchored at D-GW2 (which becomes the new serving D-GW). D-GW2 also exchanges the required PBU/PBA signaling to ensure that data traffic using prefA::MN1 still reaches the mobile node, by setting up a bidirectional tunnel between D-GW1 (anchoring D-GW) and D-GW2 (serving D-GW). +-----+ +-------+ +-------+ +-------------+ | MN1 | | D-GW1 | | D-GW2 | | CN@Internet | +-----+ +-------+ +-------+ +-------------+ | | | | | attachment | | | |<...........>| | | | prefA::/64 | | | |<------------| | | configures | | | | prefA::MN1 | | | | | (traffic using prefA::MN1) | |<------------|------------------------------->| | | | | | handover | | /............................/ | | | prefB::/64 | | |<---------------------------| | configures | | PBU | | prefB::MN1 | tunnel |<-------------| | and keeps | set-up | PBA | | using | |------------->| tunnel | prefA::MN1 | | | set-up | | (traffic using prefB::MN1) | |<---------------------------|---------------->| | (traffic using prefA::MN1) | | |<------------------------------>| | |<============>| | |<-------------------------->| | | | | | Figure 1: Basic operation of the solution Bernardos & Zuniga Expires September 15, 2016 [Page 6] Internet-Draft PMIPv6 distributed anchoring March 2016 The next sections of this draft focus on the detailed operation of the D-GWs when a mobile node has multiple flows anchored at different distributed gateways. 4. Simultaneous anchoring of multiple flows (single operator) In this section we describe the mechanisms required in the network to enable simultaneous anchoring of several flows at different D-GWs within the same operator. 4.1. The Distributed Logical Interface (DLIF) concept One of the main challenges of a network-based DMM solution is how to allow a mobile node to simultaneously send/receive traffic which is anchored at different D-GWs, and how to influence on the preference of the mobile selecting the source IPv6 address for a new communication, without requiring special support on the mobile node stack. This document defines the Distributed Logical Interface (DLIF), which is a software construct that allows to easily hide the change of anchor from the mobile node. +---------------------------------------------------+ ( Operator's ) ( core ) +---------------------------------------------------+ | | +---------------+ tunnel +---------------+ | IP stack |===============| IP stack | +---------------+ +-------+-------+ | mn1dgw1 |--+ (DLIFs) +--|mn1dgw1|mn1dgw2|--+ +---------------+ | | +-------+-------+ | | phy interface | | | | phy interface | | +---------------+ | | +---------------+ | D-GW1 (o) (o) D-GW2 (o) x x x x prefA::/64 x x prefB::/64 (AdvPrefLft=0) x x (o) | +-----+ prefA::MN1 | MN1 | prefB::MN1 (deprecated) +-----+ Figure 2: DLIF: exposing multiple routers (one per active anchoring D-GW) Bernardos & Zuniga Expires September 15, 2016 [Page 7] Internet-Draft PMIPv6 distributed anchoring March 2016 The basic idea of the DLIF concept is the following. Each serving D-GW exposes itself towards a given MN as multiple routers, one per active anchoring D-GW associated to the MN. Let's consider the example shown in Figure 2, MN1 initially attaches to D-GW1, configuring an IPv6 address (prefA::MN1) from a prefix locally anchored at D-GW1 (prefA::/64). At this stage, D-GW1 plays both the role of anchoring and serving D-GW, and also it behaves as a plain IPv6 access router. D-GW1 creates a distributed logical interface to communicate (point-to-point link) with MN1, exposing itself as a (logical) router with a specific MAC (e.g., 00:11:22:33:01:01) and IPv6 addresses (e.g., prefA::DGW1/64 and fe80:211:22ff:fe33:101/64) using the DLIF mn1dgw1. As explained below, these addresses represent the "logical" identity of D-GW1 towards MN1, and will "follow" the mobile node while roaming within the domain (note that the place where all this information is maintained and updated is out-of-scope of this draft; potential examples are to keep it on the HSS or the user's profile). If MN1 moves and attaches to a different D-GW of the domain (D-GW2 in the example of Figure 2), this D-GW will create a new logical interface (mn1dgw2) to expose itself towards MN1, providing it with a locally anchored prefix (prefB::/64). In this case, since the MN1 has another active IPv6 address anchored at a D-GW1, D-GW2 also needs to create an additional logical interface configured to exactly resemble the one used by D-GW1 to communicate with MN1. In this example, there is only one active anchoring D-GW (in addition to D-GW2, which is the serving one): D-GW1, so only the logical interface mn1dgw1 is created, but the same process would be repeated in case there were more active anchoring D-GWs involved. In order to maintain the prefix anchored at D-GW1 reachable, a tunnel between D-GW1 and D-GW2 is established and the routing is modified accordingly. The PBU/PBA signaling is used to set-up the bi- directional tunnel between D-GW1 and D-GW2, and it might also be used to convey to D-GW2 the information about the prefix(es) anchored at D-GW1 and about the addresses of the associated DLIF (i.e., mn1dgw1). Bernardos & Zuniga Expires September 15, 2016 [Page 8] Internet-Draft PMIPv6 distributed anchoring March 2016 +------------------------------------------+ +----------------------+ | D-GW1 | | D-GW2 | |+----------------------------------------+| |+--------------------+| ||+------------------++------------------+|| ||+------------------+|| |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| ||||mn3dgw1||mn3dgw2||||mn2dgw1||mn2dgw2|||| ||||mn1dgw1||mn1dgw2|||| |||| LMAC1 || LMAC2 |||| LMAC3 || LMAC4 |||| |||| LMAC5 || LMAC6 |||| |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| ||| LIFs of MN3 || LIFs of MN2 ||| ||| LIFs of MN1 ||| ||+------------------++------------------+|| ||+------------------+|| || HMAC1 (phy if D-GW1) || ||HMAC2 (phy if D-GW2)|| |+----------------------------------------+| |+--------------------+| +------------------------------------------+ +----------------------+ x x x x x x (o) (o) (o) | | | +--+--+ +--+--+ +--+--+ | MN3 | | MN2 | | MN1 | +-----+ +-----+ +-----+ Figure 3: Distributed Logical Interface concept Figure 3 shows the logical interface concept in more detail. The figure shows two D-GWs and three MNs. D-GW1 is currently serving MN2 and MN3, while D-GW2 is serving MN1. MN1, MN2 and MN3 have two active anchoring D-GWs: D-GW1 and D-GW2. Note that a serving D-GW always plays the role of anchoring D-GW for the attached (served) MNs. Each D-GW has one single physical wireless interface. As introduced before, each MN always "sees" multiple logical routers -- one per active anchoring D-GW -- independently of to which serving D-GW the MN is currently attached. From the point of view of the MN, these D-GWs are portrayed as different routers, although the MN is physically attached to one single interface . The way this is achieved is by the serving D-GW configuring different logical interfaces. If we focus on MN1, it is currently attached to D-GW2 (i.e., D-GW2 is its serving D-GW) and, therefore, it has configured an IPv6 address from D-GW2's pool (e.g., prefB::/64). D-GW2 has set- up a logical interface (mn1dgw2) on top of its wireless physical interface (phy if D-GW2) which is used to serve MN1. This interface has a logical MAC address (LMAC6), different from the hardware MAC address (HMAC2) of the physical interface of D-GW2. Over the mn1dgw2 interface, D-GW2 advertises its locally anchored prefix prefB::/64. Before attaching to D-GW2, MN1 visited D-GW1, configuring also an address locally anchored at this D-GW, which is still being used by the MN1 in active communications. MN1 keeps "seeing" an interface connecting to D-GW1, as if it were directly connected to the two Bernardos & Zuniga Expires September 15, 2016 [Page 9] Internet-Draft PMIPv6 distributed anchoring March 2016 D-GWs. This is achieved by the serving D-GW (D-GW1) configuring an additional distributed logical interface: mn1dgw1, which behaves exactly as the logical interface configured by the actual D-GW1 when MN1 was attached to it. This means that both the MAC and IPv6 addresses configured on this logical interface remain the same regardless of the physical D-GW which is serving the MN. The information required by a serving D-GW to properly configure this logical interfaces can be obtained in different ways: as part of the information conveyed in the PBA, from an external database (e.g., the HSS) or by other means. As shown in the figure, each D-GW may have several logical interfaces associated to each attached MN, having always at least one (since a serving D-GW is also an anchoring D-GW for the attached MN). In order to enforce the use of the prefix locally anchored at the serving D-GW, the router advertisements sent over those logical interfaces playing the role of anchoring D-GWs (different from the serving one) include a zero prefix lifetime. The goal is to deprecate the prefixes delegated by these D-GWs (which will be no longer serving the MN). Note that on-going communications keep on using those addresses, even if they are deprecated, so this only affects to new sessions. The distributed logical interface concept also enables the following use case. Suppose that access to a local IP network is provided by a given D-GW (e.g., D-GW1 in the example shown in Figure 2) and that the resources available at that network cannot be reached from outside the local network (e.g., cannot be accessed by an MN attached to D-GW2). This is similar to the LIPA scenario currently being consider by 3GPP. The goal is to allow an MN to be able to roam while still being able to have connectivity to this local IP network. The solution adopted to support this case makes use of RFC 4191 [RFC4191] more specific routes when the MN moves to a D-GW different from the one providing access to the local IP network (D-GW1 in the example). These routes are advertised through the distributed logical interface representing the D-GW providing access to the local network (D-GW1 in this example). In this way, if MN1 moves from D-GW1 to D-GW2, any active session that MN1 may have with a node of the local network connected to D-GW1 will survive, being the traffic forwarded via the tunnel between D-GW1 and D-GW2. Also, any potential future connection attempt towards the local network will be supported, even though MN1 is no longer attached to D-GW1. 4.2. D-GW protocol operation This section describes the D-GW operation in more detail. Figure 4 shows an example of the D-GW operation: Bernardos & Zuniga Expires September 15, 2016 [Page 10] Internet-Draft PMIPv6 distributed anchoring March 2016 1. MN1 attaches to D-GW1. This event is detected by D-GW1 (based on layer 2 signaling/triggers or the reception of a Router Solicitation sent by MN1). 2. An IPv6 prefix from the pool of locally anchored prefixes is selected by D-GW1 to be delegated to MN1 (prefA::/64). D-GW1 sets up a distributed logical interface aimed at interfacing with MN1, called mn1dgw1. D-GW1 starts sending router advertisements to MN1, including the delegated prefix. 3. D-GW1 learns if it is an attachment due to a handover (how this is done is out-of-scope of this draft). In this case it is an initial attachment, so nothing else is required. 4. The DLIF mn1dgw1 is used by D-GW1 to advertise the locally anchored prefix (prefA::/64) to MN1. Using this prefix, MN1 configures an IPv6 address (prefA::MN1/64) that can be used to start new sessions (which will be anchored at D-GW1). Traffic using the address prefA::MN1 is received at the interface mn1dgw1 and directly forwarded by D-GW1 towards its destination. Traffic between MN1 and the local network reachable via D-GW1 (localnet) is handled normally by D-GW1 (as MN1 is locally attached). 5. MN1 performs a handover to D-GW2. This event is detected by D-GW2. 6. An IPv6 prefix from the pool of locally anchored prefixes is selected by D-GW2 to be delegated to MN1 (prefB::/64). D-GW2 sets up a distributed logical interface aimed at interfacing with MN1, called mn1dgw2. D-GW2 starts sending router advertisements to MN1, including the delegated prefix. Traffic using the address prefB::MN1 is received at the interface mn1dgw2 and directly forwarded by D-GW2 towards its destination. 7. D-GW2 learns that this is a handover of MN1, and that it previously visited D-GW1. D-GW2 sends a PBU to D-GW1, which replies with a PBA. This PBA MAY include information about the prefix(es) anchored at D-GW1, the parameters needed by D-GW2 to set-up the DLIF mn1dgw1, and the prefixes of local networks reachable via D-GW (if any). Alternatively, this information MAY be obtained using a different approach (such as storing it in the HSS or some other external repository). A bi-directional tunnel between D-GW1 and D-GW2 is set-up, as well as the required routing entries. 8. D-GW2 sets up the DLIF mn1dgw1, aimed at "logically" resembling D-GW1, so MN1 does not detect any change at layer-3. D-GW2 starts sending router advertisements to MN1 through mn1dgw2, Bernardos & Zuniga Expires September 15, 2016 [Page 11] Internet-Draft PMIPv6 distributed anchoring March 2016 which include the prefix anchored at D-GW1 (prefA::/64) with zero lifetime to deprecate the prefix (or alternatively it MAY include a low Default Router Preference [RFC4191] if communication to this D-GW is still needed in the future). In this way, prefA::MN1 is not preferred for new communications. The RAs MAY also include a Route Information Option (RIO) [RFC4191] with the prefix of localnet, which is the network that is only locally reachable via D-GW1 (e.g., as in the LIPA scenarios considered by the 3GPP), so MN1 picks D-GW1 (the "logical" version of it portrayed by D-GW2) when sending traffic to that network , including the delegated prefix. Traffic using the address prefA::MN1 is received at the interface mn1dgw1 and forwarded via the tunnel with D-GW1, which then forwards it towards its destination. Traffic between MN1 and the network locally reachable via D-GW1 (localnet) is also handled via mn1dgw1 and sent through the tunnel. Bernardos & Zuniga Expires September 15, 2016 [Page 12] Internet-Draft PMIPv6 distributed anchoring March 2016 +-----+ +-------+ +-------+ +-------------+ | MN1 | | D-GW1 | | D-GW2 | | CN@Internet | +-----+ +-------+ +-------+ +-------------+ | | | | | attachment | | | |<...........>|set-up of new | | | RA@mn1dgw1 |DLIF: mn1dgw1 | | |<------------| | | configures | (prefA::/64)| | | prefA::MN1 | | | | | (traffic using prefA::MN1) | |<------------|------------------------------->| | (traffic with local net) | | |<----------->|<----> | | | | | | | handover | | /............................/set-up of new | | | RA@mn1dwg2 |DLIF: mn1dgw2 | configures |<---------------------------| | prefB::MN1 | | (prefB::/64)| | and keeps | | PBU | | using | tunnel |<-------------| | prefA::MN1 | set-up | PBA(mn1dgw1, | | | | prefA::/64, | | | | preflocalnet)| | | |------------->|set-up of tunnel | | | RA@mn1dgw1 | & DLIF mn1dgw1 | |<---------------------------| | | | (prefA::/64, lft=0, | | | RIO: preflocalnet) | | | | | | (traffic using prefB::MN1) | |<-------------------------->|<--------------->| | | | | | (traffic using prefA::MN1) | |<-------------------------->| | | |<============>| | | |<------------------------------>| | | | | | (traffic with local net) | | |<-------------------------->| | | |<============>| | | |<---> | | | | | | Figure 4: D-GW protocol operation Bernardos & Zuniga Expires September 15, 2016 [Page 13] Internet-Draft PMIPv6 distributed anchoring March 2016 4.3. Message format This section defines extensions to the Proxy Mobile IPv6 [RFC5213] protocol messages. 4.3.1. Proxy Binding Update A new flag (D) is included in the Proxy Binding Update to indicate that the Proxy Binding Update is coming from a Distributed Gateway and not from a mobile access gateway. The rest of the Proxy Binding Update format remains the same as defined in [RFC5213]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|P|D| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Distributed Gateway Flag (D) The Distributed Gateway Flag is set to indicate to the receiver of the message that the Proxy Binding Update is from a Distributed Gateway. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in Section 6.2 of [RFC6275]. The distributed gateway MUST ignore and skip any options that it does not understand. 4.3.2. Proxy Binding Acknowledgment A new flag (D) is included in the Proxy Binding Acknowledgment to indicate that the sender supports operating as a distributed gateway. The rest of the Proxy Binding Acknowledgment format remains the same as defined in [RFC5213]. Bernardos & Zuniga Expires September 15, 2016 [Page 14] Internet-Draft PMIPv6 distributed anchoring March 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|R|P|D| Reser | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Distributed Gateway Flag (D) The Distributed Gateway Flag is set to indicate that the sender of the message supports operating as a distributed gateway. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in Section 6.2 of [RFC6275]. The distributed gateway MUST ignore and skip any options that it does not understand. 4.3.3. Anchored Prefix Option A new Anchored Prefix option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgment messages exchanged between distributed gateways. This option is used for exchanging the mobile node's prefix anchored at the anchoring D-GW. There can be multiple Anchored Prefix options present in the message. The Anchored Prefix Option has an alignment requirement of 8n+4. Its format is as follows: Bernardos & Zuniga Expires September 15, 2016 [Page 15] Internet-Draft PMIPv6 distributed anchoring March 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Anchored Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA. Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 18. Reserved This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. Prefix Length 8-bit unsigned integer indicating the prefix length of the IPv6 prefix contained in the option. Anchored Prefix A sixteen-byte field containing the mobile node's IPv6 Anchored Prefix. 4.3.4. Local Prefix Option A new Local Prefix option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgment messages exchanged between distributed gateways. This option is used for exchanging a prefix of a local network that is only reachable via the anchoring D-GW. There can be multiple Local Prefix options present in the message. Bernardos & Zuniga Expires September 15, 2016 [Page 16] Internet-Draft PMIPv6 distributed anchoring March 2016 The Local Prefix Option has an alignment requirement of 8n+4. Its format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Local Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA. Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 18. Reserved This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. Prefix Length 8-bit unsigned integer indicating the prefix length of the IPv6 prefix contained in the option. Local Prefix A sixteen-byte field containing the IPv6 Local Prefix. 4.3.5. DLIF Link-local Address Option A new DLIF Link-local Address option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgment messages exchanged between distributed gateways. This option is used for exchanging the link-local address of the DLIF to be configured on the Bernardos & Zuniga Expires September 15, 2016 [Page 17] Internet-Draft PMIPv6 distributed anchoring March 2016 serving D-GW so it resembles the DLIF configured on the anchoring D-GW. The DLIF Link-local Address option has an alignment requirement of 8n+6. Its format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DLIF Link-local Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA. Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 16. DLIF Link-local Address A sixteen-byte field containing the link-local address of the logical interface. 4.3.6. DLIF Link-layer Address Option A new DLIF Link-layer Address option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgment messages exchanged between distributed gateways. This option is used for exchanging the link-layer address of the DLIF to be configured on the serving D-GW so it resembles the DLIF configured on the anchoring D-GW. The format of the DLIF Link-layer Address option is shown below. Based on the size of the address, the option MUST be aligned appropriately, as per mobility option alignment requirements specified in [RFC6275]. Bernardos & Zuniga Expires September 15, 2016 [Page 18] Internet-Draft PMIPv6 distributed anchoring March 2016 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + DLIF Link-layer Address + . ... . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA. Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. Reserved This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. DLIF Link-layer Address A variable length field containing the link-layer address of the logical interface to be configured on the serving distributed gateway. The content and format of this field (including byte and bit ordering) is as specified in Section 4.6 of [RFC4861] for carrying link-layer addresses. On certain access links, where the link- layer address is not used or cannot be determined, this option cannot be used. 5. Simultaneous anchoring of multiple flows (multiple operators) An MN may roam between D-GWs that do not belong to the same operator, and therefore might end up having multiple simultaneous flows, anchored at different operators. Since dynamically setting up tunnels between different operators (i.e., between D-GWs belonging to different operators) is usually not supported, a solution should be devised to ensure session continuity in this scenario, even if it is at the cost of a sub-optimal routing. Bernardos & Zuniga Expires September 15, 2016 [Page 19] Internet-Draft PMIPv6 distributed anchoring March 2016 In this section we describe the required extensions to support inter- domain operation. The basic solution consists in using a centralized LMA (usually located in the home domain) as top-level anchor to guarantee session continuity when crossing operator borders. We assume that the necessary roaming agreements are in place in order to support setting up tunnels between the LMA located at the home domain of the MN and the visited D-GWs. +---------------------------------------------------+ ( Home Operator's core ) ( ) ( +-----+ ) ( /| LMA |\ ) ( //+-----+\\ ) ( // \\ ) +------------------//-----------\\------------------+ . (tunnel) // \\ (tunnel) . . // \\ . . // \\ . . // \\ . +---------------+ +---------------+ | IP stack | | IP stack | +---------------+ +-------+-------+ | mn1dgw1 |--+ (DLIFs) +--|mn1dgw1|mn1dgw2|--+ +---------------+ | | +-------+-------+ | | phy interface | | | | phy interface | | +---------------+ | | +---------------+ | D-GW1@OperatorA (o) (o) D-GW2@OperatorB (o) x x x x prefA::/64 x x prefB::/64 (AdvPrefLft=0) x x (o) | +-----+ prefA::MN1 | MN1 | prefB::MN1 (deprecated) +-----+ Figure 5: Simultaneous anchoring of multiple flows across multiple operators Figure 5 shows an example of the inter-domain operation. MN1 initially attaches to D-GW1 (which belongs to OperatorA), and configures prefA::MN1 address out of one prefix anchored at D-GW1 (prefA::/64). If MN1 moves to D-GW2, which is managed by OperatorB, tunnels need to be established via the centralized LMA at the MN1's operators core, since we assume that no direct tunneling is possible between D-GWs belonging to different operators. In this case, D-GW3 Bernardos & Zuniga Expires September 15, 2016 [Page 20] Internet-Draft PMIPv6 distributed anchoring March 2016 establishes one tunnel with the centralized LMA to send/receive traffic using prefA::/64. From the point of view of D-GW2, the operation is just as if the LMA was the D-GW anchoring this prefix. Analogously, the LMA establishes one tunnel with D-GW1 (from the point of view of D-GW1, the LMA is the current serving D-GW of MN1). Regarding the signaling, it is similar to the intra-operator scenario, though in this case the PBU/PBA sequence is performed twice, once between D-GW2 and the LMA, and another one between the LMA and D-GW1 (i.e., because two different tunnels are created). 6. IANA Considerations This document defines new mobility options that require IANA actions. 7. Security Considerations The protocol extensions defined in this document share the same security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended that the signaling messages, Proxy Binding Update and Proxy Binding Acknowledgment, exchanged between the distributed gateways, or between a distributed gateway and a centralized local mobility anchor, are protected using IPsec using the established security association between them. This essentially eliminates the threats related to the impersonation of a distributed gateway or the local mobility anchor. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, . Bernardos & Zuniga Expires September 15, 2016 [Page 21] Internet-Draft PMIPv6 distributed anchoring March 2016 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . 8.2. Informative References [I-D.bernardos-dmm-pmip] Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based solution for Distributed Mobility Management", draft- bernardos-dmm-pmip-05 (work in progress), September 2015. [I-D.seite-dmm-dma] Seite, P., Bertin, P., and J. Lee, "Distributed Mobility Anchoring", draft-seite-dmm-dma-07 (work in progress), February 2014. [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, . [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and CJ. Bernardos, "Distributed Mobility Management: Current Practices and Gap Analysis", RFC 7429, DOI 10.17487/ RFC7429, January 2015, . [commag.dmm-standards] Zuniga, JC., Bernardos, CJ., de la Oliva, A., Melia, T., Costa, R., and A. Reznik, "Distributed mobility management: a standards landscape", IEEE Communications Magazine Vol. 51, No. 3, March 2013. Appendix A. Comparison with Requirement document In this section we descrbe how our solution addresses the DMM requirements listed in [RFC7333]. A.1. Distributed mobility management "IP mobility, network access solutions, and forwarding solutions provided by DMM MUST enable traffic to avoid traversing a single mobility anchor far from the optimal route." In our solution, the anchoring D-GW is responsible to handle the mobility for those IP flows started when the MN is attached to it. As long as the MN remains connected to the anchoring D-GW's access links, the IP packets of such flows can benefit from the optimal Bernardos & Zuniga Expires September 15, 2016 [Page 22] Internet-Draft PMIPv6 distributed anchoring March 2016 path. When the MN moves to another D-GW, the path becomes non- optimal for ongoing flows, but newly started IP sessions are forwarded by the serving D-GW through the optimal path. A.2. Bypassable network-layer mobility support for each application session "DMM solutions MUST enable network-layer mobility, but it MUST be possible for any individual active application session (flow) to not use it. Mobility support is needed, for example, when a mobile host moves and an application cannot cope with a change in the IP address. Mobility support is also needed when a mobile router changes its IP address as it moves together with a host and, in the presence of ingress filtering, an application in the host is interrupted. However, mobility support at the network layer is not always needed; a mobile node can often be stationary, and mobility support can also be provided at other layers. It is then not always necessary to maintain a stable IP address or prefix for an active application session." The solution operates at the IP layer, hence upper layers are totally transparent to the mobility operations. In particular, ongoing IP sessions are not disrupted after a change of access network. The routability of the old address is ensured by the IP tunnel with the anchoring D-GW. New IP sessions are started with the new address. From the application's perspective, those processes which sockets are bound to a unique IP address do not suffer any impact. For the other applications, the sockets bound to the old address are preserved, whereas next sockets use the new address. Additionally, the use of the DLIF makes easier to implement more complex policies regarding how traffic is forwarded at the D-GW. A.3. IPv6 deployment "DMM solutions SHOULD target IPv6 as the primary deployment environment and SHOULD NOT be tailored specifically to support IPv4, particularly in situations where private IPv4 addresses and/or NATs are used." The solution targets IPv6 only. A.4. Existing mobility protocols "A DMM solution MUST first consider reusing and extending IETF standard protocols before specifying new protocols." Bernardos & Zuniga Expires September 15, 2016 [Page 23] Internet-Draft PMIPv6 distributed anchoring March 2016 The is derived from the operations and messages specified in [RFC5213]. A.5. Coexistence with deployed networks/hosts and operability across different networks "A DMM solution may require loose, tight, or no integration into existing mobility protocols and host IP stacks. Regardless of the integration level, DMM implementations MUST be able to coexist with existing network deployments, end hosts, and routers that may or may not implement existing mobility protocols. Furthermore, a DMM solution SHOULD work across different networks, possibly operated as separate administrative domains, when the needed mobility management signaling, forwarding, and network access are allowed by the trust relationship between them." The solution can be extended to provide a fallback mechanism to operate as legacy Proxy Mobile IPv6. It is necessary to instruct D-GWs to always establish a tunnel with the same anchoring D-GW, working as LMA. A.6. Operation and management considerations "A DMM solution needs to consider configuring a device, monitoring the current operational state of a device, and responding to events that impact the device, possibly by modifying the configuration and storing the data in a format that can be analyzed later. The proposed solution can re-use existing mechanisms defined for the operation and management of Proxy Mobile IPv6. A.7. Security considerations "A DMM solution MUST support any security protocols and mechanisms needed to secure the network and to make continuous security improvements. In addition, with security taken into consideration early in the design, a DMM solution MUST NOT introduce new security risks or amplify existing security risks that cannot be mitigated by existing security protocols and mechanisms." The proposed solution does not specify a security mechanism, given that the same mechanism for PMIPv6 can be used. A.8. Multicast "DMM SHOULD enable multicast solutions to be developed to avoid network inefficiency in multicast traffic delivery." Bernardos & Zuniga Expires September 15, 2016 [Page 24] Internet-Draft PMIPv6 distributed anchoring March 2016 This solution in its current version does not specify any support for multicast traffic, which is left for study in future versions. Appendix B. Implementation experience The DLIF concept can be easily implemented using features that are usually available on several OSs. Among the possible mechanisms that can be used to do it, the Linux macvlan support allows the creation of different logical interfaces over the same physical one. Each logical interface appears as a regular interface to the Linux OS (which can be configured normally), and it supports configuring the MAC address exposed by the logical interface. The destination MAC address is used by the OS to decide which logical interface (configured on top of a physical interface) is in charge of processing an incoming L2 frame. The EU FP7 MEDIEVAL project implemented a prototype of the DLIF concept using the Linux macvlan support, the radvd daemon, the Linux Advanced Routing and Traffic Control features and the standard iproute2 collection of utilities: o The macvlan support enables iproute2 tools to be able to create, destroy and configure DLIFs on demand over a single physical interface. One of the important features that needs to be configured is the logical MAC address exposed by the DLIF, as well as the IPv6 addresses, as they should remain the same regardless of the serving D-GW where the DLIF is configured. o Since the distributed logical interfaces created using the macvlan support appear as regular network interfaces, they can be used normally in the radvd configuration file. Them, by dynamically modifying the radvd configuration file and reloading it, we can control the router advertisements sent to each MN (e.g., advertizing new IPv6 prefixes, deprecating prefixes anchored at other serving D-GWs, announcing RFC 4191 specific routes or changing router preferences). o Each time a DLIF is created, it is also needed to properly configure source-based IPv6 routes, as well as tunnels (in case of handover). This is supported by the Linux Advanced Routing and Traffic Control features. o Last, but not least, current Linux kernels support the configuration of RFC 4191 specific routes (by processing Route Information Options contained in RAs). The kernel support can be easily enabled by using the net.conf.ipv6.*.accept_ra_rt_info_max_plen kernel configuration parameter. Bernardos & Zuniga Expires September 15, 2016 [Page 25] Internet-Draft PMIPv6 distributed anchoring March 2016 The DLIF concept is implemented by the Open Distributed Mobility Management (ODMM) project (http://www.odmm.net/), as part of the Mobility Anchors Distribution for PMIPv6 (MAD-PMIPv6). The ODMM platform is intended to foster DMM development and deployment, by serving as a framework to host open source implementations. Appendix C. Public demonstrations The DLIF concept has been demonstrated, together with the network- based DMM solution described in [I-D.bernardos-dmm-pmip], during the 83rd IETF in Paris (March 2012) and the 87th IETF in Berlin (August 2013). The first demo showcased a scenario composed of three "anchor routers", a "centralized LMA" for control plane, a "mobile node" and two "correspondent nodes" (one of them being a legacy IPv6 camera). The mobile node could move between the different anchor routers, getting a different locally anchor IPv6 address at each location, and being the reachability of each address maintained. In the second demo, integration with content delivery nodes (CDNs) was also shown, showcasing the advantages that the use of a DMM solution brings to this popular scenario. These concepts were further explored in the EU project MEDIEVAL. Authors' Addresses Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Email: cjbc@it.uc3m.es URI: http://www.it.uc3m.es/cjbc/ Juan Carlos Zuniga InterDigital Communications, LLC 1000 Sherbrooke Street West, 10th floor Montreal, Quebec H3A 3G4 Canada Email: JuanCarlos.Zuniga@InterDigital.com URI: http://www.InterDigital.com/ Bernardos & Zuniga Expires September 15, 2016 [Page 26]