diff options
Diffstat (limited to 'doc/rfc/rfc8885.txt')
| -rw-r--r-- | doc/rfc/rfc8885.txt | 1317 |
1 files changed, 1317 insertions, 0 deletions
diff --git a/doc/rfc/rfc8885.txt b/doc/rfc/rfc8885.txt new file mode 100644 index 0000000..35a1266 --- /dev/null +++ b/doc/rfc/rfc8885.txt @@ -0,0 +1,1317 @@ + + + + +Internet Engineering Task Force (IETF) CJ. Bernardos +Request for Comments: 8885 A. de la Oliva +Category: Experimental UC3M +ISSN: 2070-1721 F. Giust + Athonet + JC. Zúñiga + SIGFOX + A. Mourad + InterDigital + October 2020 + + + Proxy Mobile IPv6 Extensions for Distributed Mobility Management + +Abstract + + Distributed Mobility Management solutions allow networks to be set up + in such a way that traffic is distributed optimally and centrally + deployed anchors are not relied upon to provide IP mobility support. + + There are many different approaches to address Distributed Mobility + Management -- for example, extending network-based mobility protocols + (like Proxy Mobile IPv6) or client-based mobility protocols (like + 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 the + mobility anchor and access router). The mobility anchor and access + router is an enhanced access router that is also able to operate as a + local mobility anchor or mobility access gateway on a per-prefix + basis. The document focuses on the required extensions to + effectively support the simultaneous anchoring several flows at + different distributed gateways. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are candidates for any level of + Internet Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8885. + +Copyright Notice + + Copyright (c) 2020 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 + (https://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 + 1.1. Requirements Language + 2. Terminology + 3. PMIPv6 DMM Extensions + 3.1. Initial Registration + 3.2. The CMD as PBU/PBA Relay + 3.3. The CMD as MAAR Locator + 3.4. The CMD as PBU/PBA Proxy + 3.5. De-registration + 3.6. Retransmissions and Rate Limiting + 3.7. The Distributed Logical Interface (DLIF) Concept + 4. Message Format + 4.1. Proxy Binding Update + 4.2. Proxy Binding Acknowledgement + 4.3. Anchored Prefix Option + 4.4. Local Prefix Option + 4.5. Previous MAAR Option + 4.6. Serving MAAR Option + 4.7. DLIF Link-Local Address Option + 4.8. DLIF Link-Layer Address Option + 5. IANA Considerations + 6. Security Considerations + 7. References + 7.1. Normative References + 7.2. Informative References + Acknowledgements + Authors' Addresses + +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) [RFC7333]. + + The two most relevant examples of current IP mobility solutions are + Mobile IPv6 [RFC6275] and Proxy Mobile IPv6 (PMIPv6) [RFC5213]. + These solutions offer mobility support at the cost of handling + operations at a cardinal point (i.e., the mobility anchor) and + burdening it with data forwarding and control mechanisms for a large + number of users. The mobility anchor is the home agent for Mobile + IPv6 and the local mobility anchor for PMIPv6. As stated in + [RFC7333], centralized mobility solutions are prone to several + problems and limitations: longer (sub-optimal) routing paths, + scalability problems, signaling overhead (and most likely a longer + associated handover latency), more complex network deployment, higher + vulnerability due to the existence of a potential single point of + failure, and lack of granularity of the mobility management service + (i.e., mobility is offered on a per-node basis because it is not + possible to define finer granularity policies, for example, on a per- + application basis). + + The purpose of DMM is to overcome the limitations of the traditional + centralized mobility management [RFC7333] [RFC7429]; the main concept + behind DMM solutions is indeed bringing the mobility anchor closer to + the mobile node (MN). Following this idea, the central anchor is + moved to the edge of the network and is deployed in the default + gateway of the MN. That is, the first elements that provide IP + connectivity to a set of MNs are also the mobility managers for those + MNs. In this document, we call these entities Mobility Anchors and + Access Routers (MAARs). + + This document focuses on network-based DMM; hence, the starting point + is making PMIPv6 work in a distributed manner [RFC7429]. Mobility is + handled by the network without the MN's involvement. But differently + from PMIPv6, when the MN moves from one access network to another, + the router anchoring the MN's address may change, hence requiring + signaling between the anchors to retrieve the MN's previous + location(s). Also, a key aspect of network-based DMM is that a + prefix pool belongs exclusively to each MAAR in the sense that those + prefixes are assigned by the MAAR to the MNs attached to it and are + routable at that MAAR. Prefixes are assigned to MNs attached to a + MAAR at that time, but remain with those MNs as mobility occurs, + remaining always routable at that MAAR as well as towards the MN + itself. + + We consider partially distributed schemes, where only the data plane + is distributed among access routers similar to mobile access gateways + (MAGs), whereas the control plane is kept centralized towards a + cardinal node (used as an information store), which is discharged + from any route management and MN's data forwarding tasks. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. Terminology + + The following terms used in this document are defined in the PMIPv6 + specification [RFC5213]: + + BCE: Binding Cache Entry + + LMA: Local Mobility Anchor + + MAG: Mobile Access Gateway + + MN: Mobile Node + + P-CoA: Proxy Care-of Address + + PBA: Proxy Binding Acknowledgement + + PBU: Proxy Binding Update + + The following terms used in this document are defined in the Mobile + IPv6 (MIPv6) specification [RFC6275]: + + CN: Correspondent Node + + The following terms are used in this document: + + Home Control-Plane Anchor (Home-CPA or H-CPA): + The Home-CPA function hosts the MN's mobility session. There can + be more than one mobility session for an MN, and those sessions + may be anchored on the same or different Home-CPAs. The Home-CPA + will interface with the Home-DPA for managing the forwarding + state. + + Home Data Plane Anchor (Home-DPA or H-DPA): + The Home-DPA is the topological anchor for the MN's IP addresses + and/or prefixes. The Home-DPA is chosen by the Home-CPA on a + session basis. The Home-DPA is in the forwarding path for all the + MN's IP traffic. + + Access Control Plane Node (Access-CPN or A-CPN): + The Access-CPN is responsible for interfacing with the MN's Home- + CPA and the Access-DPN. The Access-CPN has a protocol interface + to the Home-CPA. + + Access Data Plane Node (Access-DPN or A-DPN): + The Access-DPN function is hosted on the first-hop router where + the MN is attached. This function is not hosted on a Layer 2 (L2) + bridging device such as an eNode(B) or Access Point. + + The following terms are defined and used in this document: + + MAAR (Mobility Anchor and Access Router): + First-hop router where the MNs attach. It also plays the role of + mobility manager for the IPv6 prefixes it anchors, running the + functionalities of PMIP's MAG and LMA. Depending on the prefix, + it plays the role of Access-DPN, Home-DPA, and Access-CPN. + + CMD (Central Mobility Database): + The node that stores the BCEs allocated for the MNs in the + mobility domain. It plays the role of Home-CPA. + + P-MAAR (Previous MAAR): + When an MN moves to a new point of attachment, a new MAAR might be + allocated as its anchor point for future IPv6 prefixes. The MAAR + that served the MN prior to new attachment becomes the P-MAAR. It + is still the anchor point for the IPv6 prefixes it had allocated + to the MN in the past and serves as the Home-DPA for flows using + these prefixes. There might be several P-MAARs serving an MN in + cases when the MN is frequently switching points of attachment + while maintaining long-lasting flows. + + S-MAAR (Serving MAAR): + The MAAR to which the MN is currently attached. Depending on the + prefix, it plays the role of Access-DPN, Home-DPA, and Access-CPN. + + Anchoring MAAR: + A MAAR anchoring an IPv6 prefix used by an MN. + + DLIF (Distributed Logical Interface): + It is a logical interface at the IP stack of the MAAR. For each + active prefix used by the MN, the S-MAAR has a DLIF configured + (associated with each MAAR still anchoring flows). In this way, + an S-MAAR exposes itself towards each MN as multiple routers, one + as itself and one per P-MAAR. + +3. PMIPv6 DMM Extensions + + The solution consists of decoupling the entities that participate in + the data and the control planes: the data plane becomes distributed + and managed by the MAARs near the edge of the network, while the + control plane, besides those on the MAARs, relies on a central entity + called the Central Mobility Database (CMD). In the proposed + architecture, the hierarchy present in PMIPv6 between LMA and MAG is + preserved but with the following substantial variations: + + * The LMA is discharged from the data forwarding role; only the + Binding Cache and its management operations are maintained. + Hence, the LMA is renamed as "CMD", which is therefore a Home-CPA. + Also, the CMD is able to send and parse both PBU and PBA messages. + + * The MAG is enriched with the LMA functionalities, hence the name + Mobility Anchor and Access Router (MAAR). It maintains a local + Binding Cache for the MNs that are attached to it, and it is able + to send and parse PBU and PBA messages. + + * The Binding Cache will be extended to include information + regarding P-MAARs where the MN was anchored and still retains + active data sessions. + + * Each MAAR has a unique set of global prefixes (which are + configurable) that can be allocated by the MAAR to the MNs but + must be exclusive to that MAAR, i.e., no other MAAR can allocate + the same prefixes. + + The MAARs leverage the CMD to access and update information related + to the MNs, which is stored as mobility sessions; hence, a + centralized node maintains a global view of the network status. The + CMD is queried whenever an MN is detected joining/leaving the + mobility domain. It might be a fresh attachment, a detachment, or a + handover, but as MAARs are not aware of past information related to a + mobility session, they contact the CMD to retrieve the data of + interest and eventually take the appropriate action. The procedure + adopted for the query and the message exchange sequence might vary to + optimize the update latency and/or the signaling overhead. Here, one + method for the initial registration and three different approaches + for updating the mobility sessions using PBUs and PBAs are presented. + Each approach assigns a different role to the CMD: + + * The CMD is a PBU/PBA relay; + + * The CMD is only a MAAR locator; + + * The CMD is a PBU/PBA proxy. + + The solution described in this document allows per-prefix anchoring + decisions -- for example, to support the anchoring of some flows at a + central Home-DPA (like a traditional LMA) or to enable an application + to switch to the locally anchored prefix to gain route optimization, + as indicated in [RFC8563]. This type of per-prefix treatment would + potentially require additional extensions to the MAARs and signaling + between the MAARs and the MNs to convey the per-flow anchor + preference (central, distributed), which are not covered in this + document. + + Note that an MN may move across different MAARs, which might result + in several P-MAARs existing at a given moment of time, each of them + anchoring a different prefix used by the MN. + +3.1. Initial Registration + + Initial registration is performed when an MN attaches to a network + for the first time (rather than attaching to a new network after + moving from a previous one). + + In this description (shown in Figure 1), it is assumed that: + + 1. The MN is attaching to MAAR1. + + 2. The MN is authorized to attach to the network. + + Upon MN attachment, the following operations take place: + + 1. MAAR1 assigns a global IPv6 prefix from its own prefix pool to + the MN (Pref1). It also stores this prefix (Pref1) in the + locally allocated temporary BCE. + + 2. MAAR1 sends a PBU [RFC5213] with Pref1 and the MN's MN-ID to the + CMD. + + 3. Since this is an initial registration, the CMD stores a BCE + containing the MN-ID, Pref1, and MAAR1's address (as a Proxy-CoA) + as the primary fields. + + 4. The CMD replies with a PBA with the usual options defined in + PMIPv6 [RFC5213], meaning that the MN's registration is fresh and + no past status is available. + + 5. MAAR1 stores the BCE described in (1) and unicasts a Router + Advertisement (RA) to the MN with Pref1. + + 6. The MN uses Pref1 to configure an IPv6 address (IP1) (e.g., with + stateless address autoconfiguration (SLAAC)). + + Note that: + + 1. Alternative IPv6 autoconfiguration mechanisms can also be used, + though this document describes the SLAAC-based one. + + 2. IP1 is routable at MAAR1 in the sense that it is on the path of + packets addressed to the MN. + + 3. MAAR1 acts as a plain router for packets destined to the MN as no + encapsulation or special handling takes place. + + In the diagram shown in Figure 1 (and subsequent diagrams), the flow + of packets is presented using '*'. + + +-----+ +---+ +--+ + |MAAR1| |CMD| |CN| + +-----+ +---+ +*-+ + | | * + MN | * +---+ + attach. | ***** _|CMD|_ + detection | flow1 * / +-+-+ \ + | | * / | \ + local BCE | * / | \ + allocation | * / | \ + |--- PBU -->| +---*-+-' +--+--+ `+-----+ + | BCE | * | | | | | + | creation |MAAR1+------+MAAR2+-----+MAAR3| + |<-- PBA ---| | * | | | | | + local BCE | +---*-+ +-----+ +-----+ + finalized | * + | | Pref1 * + | | +*-+ + | | |MN| + | | +--+ + + Operations sequence Packet flow + + Figure 1: First Attachment to the Network + + Note that the registration process does not change regardless of the + CMD's modes (relay, locator, or proxy) described in the following + sections. The procedure is depicted in Figure 1. + +3.2. The CMD as PBU/PBA Relay + + Upon MN mobility, if the CMD behaves as a PBU/PBA relay, the + following operations take place: + + 1. When the MN moves from its current point of attachment and + attaches to MAAR2 (now the S-MAAR), MAAR2 reserves an IPv6 prefix + (Pref2), stores a temporary BCE, and sends a PBU to the CMD for + registration. + + 2. Upon PBU reception and BC lookup, the CMD retrieves an already + existing entry for the MN and binds the MN-ID to its former + location; thus, the CMD forwards the PBU to the MAAR indicated as + Proxy-CoA (MAAR1) and includes a new mobility option to + communicate the S-MAAR's global address to MAAR1 (defined as the + Serving MAAR option in Section 4.6). The CMD updates the P-CoA + field in the BCE related to the MN with the S-MAAR's address. + + 3. Upon PBU reception, MAAR1 can install a tunnel on its side + towards MAAR2 and the related routes for Pref1. Then MAAR1 + replies to the CMD with a PBA (including the option mentioned + before) to ensure that the new location has successfully changed. + The PBA contains the prefix anchored at MAAR1 in the Home Network + Prefix option. + + 4. The CMD, after receiving the PBA, updates the BCE and populates + an instance of the P-MAAR list. The P-MAAR list is an additional + field on the BCE that contains an element for each P-MAAR + involved in the MN's mobility session. The list element contains + the P-MAAR's global address and the prefix it has delegated. + Also, the CMD sends a PBA to the new S-MAAR, which contains the + previous Proxy-CoA and the prefix anchored to it embedded into a + new mobility option called the Previous MAAR option (defined in + Section 4.5). Then, upon PBA arrival, a bidirectional tunnel can + be established between the two MAARs, and new routes are set + appropriately to recover the IP flow(s) carrying Pref1. + + 5. Now, packets destined for Pref1 are first received by MAAR1, + encapsulated into the tunnel, and forwarded to MAAR2, which + finally delivers them to their destination. In the uplink, when + the MN transmits packets using Pref1 as a source address, they + are sent to MAAR2 (as it is the MN's new default gateway) and + then tunneled to MAAR1, which routes them towards the next hop to + the destination. Conversely, packets carrying Pref2 are routed + by MAAR2 without any special packet handling both for the uplink + and downlink. + + +-----+ +---+ +-----+ +--+ +--+ + |MAAR1| |CMD| |MAAR2| |CN| |CN| + +-----+ +---+ +-----+ +*-+ +*-+ + | | | * * + | | MN * +---+ * + | | attach. ***** _|CMD|_ * + | | det. flow1 * / +-+-+ \ *flow2 + | |<-- PBU ---| * / | \ * + | BCE | * / | ******* + | check+ | * / | * \ + | update | +---*-+-' +--+-*+ `+-----+ + |<-- PBU*---| | | * | | *| | | + route | | |MAAR1|______|MAAR2+-----+MAAR3| + update | | | **(______)** *| | | + |--- PBA*-->| | +-----+ +-*--*+ +-----+ + | BCE | * * + | update | Pref1 * *Pref2 + | |--- PBA*-->| +*--*+ + | | route ---move-->|*MN*| + | | update +----+ + + Operations sequence Data Packet flow + PBU/PBA messages with * contain + a new mobility option + + Figure 2: Scenario after a Handover, CMD as Relay + + For MN's next movements, the process is repeated, but the number of + P-MAARs involved increases (according to the number of prefixes that + the MN wishes to maintain). Indeed, once the CMD receives the first + PBU from the new S-MAAR, it forwards copies of the PBU to all the + P-MAARs indicated in the BCE, namely the P-MAAR registered as the + current P-CoA (i.e., the MAAR prior to handover) plus the ones in the + P-MAAR list. Those P-MAARs reply with a PBA to the CMD, which + aggregates all of the PBAs into one PBA to notify the S-MAAR, which + finally can establish the tunnels with the P-MAARs. + + It should be noted that this design separates the mobility management + at the prefix granularity, and it can be tuned in order to erase old + mobility sessions when not required, while the MN is reachable + through the latest prefix acquired. Moreover, the latency associated + with the mobility update is bound to the PBA sent by the furthest + P-MAAR, in terms of RTT, that takes the longest time to reach the + CMD. The drawback can be mitigated by introducing a timeout at the + CMD, by which, after its expiration, all the PBAs so far collected + are transmitted, and the remaining are sent later upon their arrival. + Note that, in this case, the S-MAAR might receive multiple PBAs from + the CMD in response to a PBU. The CMD SHOULD follow the + retransmissions and rate-limiting considerations described in + Section 3.6, especially when aggregating and relaying PBAs. + + When there are multiple P-MAARs, e.g., k MAARs, a single PBU received + by the CMD triggers k outgoing packets from a single incoming packet. + This may lead to packet bursts originating from the CMD, albeit to + different targets. Pacing mechanisms MUST be introduced to avoid + bursts on the outgoing link. + +3.3. The CMD as MAAR Locator + + The handover latency experienced in the approach shown before can be + reduced if the P-MAARs are allowed to directly signal their + information to the new S-MAAR. This procedure reflects what was + described in Section 3.2 up to the moment the P-MAAR receives the PBU + with the Serving MAAR option. At that point, a P-MAAR is aware of + the new MN's location (because of the S-MAAR's address in the Serving + MAAR option), and, besides sending a PBA to the CMD, it also sends a + PBA to the S-MAAR, including the prefix it is anchoring. This latter + PBA does not need to include new options, as the prefix is embedded + in the Home Network Prefix (HNP) option and the P-MAAR's address is + taken from the message's source address. The CMD is released from + forwarding the PBA to the S-MAAR as the latter receives a copy + directly from the P-MAAR with the necessary information to build the + tunnels and set the appropriate routes. Figure 3 illustrates the new + message sequence. The data forwarding is unaltered. + + +-----+ +---+ +-----+ +--+ +--+ + |MAAR1| |CMD| |MAAR2| |CN| |CN| + +-----+ +---+ +-----+ +*-+ +*-+ + | | | * * + | | MN * +---+ * + | | attach. ***** _|CMD|_ * + | | det. flow1 * / +-+-+ \ *flow2 + | |<-- PBU ---| * / | \ * + | BCE | * / | ******* + | check+ | * / | * \ + | update | +---*-+-' +--+-*+ `+-----+ + |<-- PBU*---| | | * | | *| | | + route | | |MAAR1|______|MAAR2+-----+MAAR3| + update | | | **(______)** *| | | + |--------- PBA -------->| +-----+ +-*--*+ +-----+ + |--- PBA*-->| route * * + | BCE update Pref1 * *Pref2 + | update | +*--*+ + | | | ---move-->|*MN*| + | | | +----+ + + Operations sequence Data Packet flow + PBU/PBA messages with * contain + a new mobility option + + Figure 3: Scenario after a Handover, CMD as Locator + +3.4. The CMD as PBU/PBA Proxy + + A further enhancement of previous solutions can be achieved when the + CMD sends the PBA to the new S-MAAR before notifying the P-MAARs of + the location change. Indeed, when the CMD receives the PBU for the + new registration, it is already in possession of all the information + that the new S-MAAR requires to set up the tunnels and the routes. + Thus, the PBA is sent to the S-MAAR immediately after a PBU is + received, including the Previous MAAR option in this case. In + parallel, a PBU is sent by the CMD to the P-MAARs containing the + Serving MAAR option to notify them about the new MN's location so + that they receive the information to establish the tunnels and routes + on their side. When P-MAARs complete the update, they send a PBA to + the CMD to indicate that the operation has concluded and the + information is updated in all network nodes. This procedure is + obtained from the first procedure rearranging the order of the + messages, but the parameters communicated are the same. This scheme + is depicted in Figure 4, where, again, the data forwarding is kept + untouched. + + +-----+ +---+ +-----+ +--+ +--+ + |MAAR1| |CMD| |MAAR2| |CN| |CN| + +-----+ +---+ +-----+ +*-+ +*-+ + | | | * * + | | MN * +---+ * + | | attach. ***** _|CMD|_ * + | | det. flow1 * / +-+-+ \ *flow2 + | |<-- PBU ---| * / | \ * + | BCE | * / | ******* + | check+ | * / | * \ + | update | +---*-+-' +--+-*+ `+-----+ + |<-- PBU*---x--- PBA*-->| | * | | *| | | + route | route |MAAR1|______|MAAR2+-----+MAAR3| + update | update | **(______)** *| | | + |--- PBA*-->| | +-----+ +-*--*+ +-----+ + | BCE | * * + | update | Pref1 * *Pref2 + | | | +*--*+ + | | | ---move-->|*MN*| + | | | +----+ + + Operations sequence Data Packet flow + PBU/PBA messages with * contain + a new mobility option + + Figure 4: Scenario after a Handover, CMD as Proxy + +3.5. De-registration + + The de-registration mechanism devised for PMIPv6 cannot be used as is + in this solution because each MAAR handles an independent mobility + session (i.e., a single prefix or a set of prefixes) for a given MN, + whereas the aggregated session is stored at the CMD. Indeed, if a + P-MAAR initiates a de-registration procedure because the MN is no + longer present on the MAAR's access link, it removes the routing + state for the prefix(es), that would be deleted by the CMD as well, + hence defeating any prefix continuity attempt. The simplest approach + to overcome this limitation is to deny a P-MAAR to de-register a + prefix, that is, allowing only an S-MAAR to de-register the whole MN + session. This can be achieved by first removing any L2 detachment + event so that de-registration is triggered only when the binding + lifetime expires, hence providing a guard interval for the MN to + connect to a new MAAR. Then, a change in the MAAR operations is + required, and at this stage, two possible solutions can be deployed: + + * A P-MAAR stops the BCE timer upon receiving a PBU from the CMD + containing a "Serving MAAR" option. In this way, only the S-MAAR + is allowed to de-register the mobility session, arguing that the + MN definitely left the domain. + + * P-MAARs can, upon BCE expiry, send de-registration messages to the + CMD, which, instead of acknowledging the message with a 0 + lifetime, sends back a PBA with a non-zero lifetime, hence + renewing the session if the MN is still connected to the domain. + +3.6. Retransmissions and Rate Limiting + + The node sending PBUs (the CMD or S-MAAR) SHOULD make use of the + timeout to also deal with missing PBAs (to retransmit PBUs). The + INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD be used for configuring the + retransmission timer. The retransmissions by the node MUST use an + exponential backoff process in which the timeout period is doubled + upon each retransmission until either the node receives a response or + the timeout period reaches the value MAX_BINDACK_TIMEOUT [RFC6275]. + The node MAY continue to send these messages at this slower rate + indefinitely. The node MUST NOT send PBU messages to a particular + node more than MAX_UPDATE_RATE times within a second [RFC6275]. + +3.7. The Distributed Logical Interface (DLIF) Concept + + One of the main challenges of a network-based DMM solution is how to + allow a MN to simultaneously send/receive traffic that is anchored at + different MAARs and how to influence the MN's selection process of + its source IPv6 address for a new flow without requiring special + support from the MN's IP stack. This document defines the DLIF, + which is a software construct in the MAAR that can easily hide the + change of associated anchors from the MN. + + +---------------------------------------------------+ + ( Operator's ) + ( core ) + +---------------------------------------------------+ + | | + +---------------+ tunnel +---------------+ + | IP stack |===============| IP stack | + +---------------+ +-------+-------+ + | mn1mar1 |--+ (DLIFs) +--|mn1mar1|mn1mar2|--+ + +---------------+ | | +-------+-------+ | + | phy interface | | | | phy interface | | + +---------------+ | | +---------------+ | + MAAR1 (o) (o) MAAR2 (o) + x x + x x + prefA::/64 x x prefB::/64 + (AdvPrefLft=0) x x + (o) + | + +-----+ + prefA::MN1 | MN1 | prefB::MN1 + (deprecated) +-----+ + + Figure 5: DLIF: Exposing Multiple Routers (One per P-MAAR) + + The basic idea of the DLIF concept is the following: each S-MAAR + exposes itself to a given MN as multiple routers, one per P-MAAR + associated with the MN. Let's consider the example shown in + Figure 5: MN1 initially attaches to MAAR1, configuring an IPv6 + address (prefA::MN1) from a prefix locally anchored at MAAR1 + (prefA::/64). At this stage, MAAR1 plays the role of both anchoring + and serving MAAR and also behaves as a plain IPv6 access router. + MAAR1 creates a DLIF to communicate (through a point-to-point link) + with MN1, exposing itself as a (logical) router with specific MAC and + IPv6 addresses (e.g., prefA::MAAR1/64 and fe80::MAAR1/64) using the + DLIF mn1mar1. As explained below, these addresses represent the + "logical" identity of MAAR1 for MN1 and will "follow" the MN while + roaming within the domain (note that the place where all this + information is maintained and updated is out of scope of this + document; potential examples are to keep it on the home subscriber + server -- HSS -- or the user's profile). + + If MN1 moves and attaches to a different MAAR of the domain (MAAR2 in + the example of Figure 5), this MAAR will create a new logical + interface (mn1mar2) to expose itself to MN1, providing it with a + locally anchored prefix (prefB::/64). In this case, since the MN1 + has another active IPv6 address anchored at MAAR1, MAAR2 also needs + to create an additional logical interface configured to resemble the + one used by MAAR1 to communicate with MN1. In this example, MAAR1 is + the only P-MAAR (MAAR2 is the same as S-MAAR), so only the logical + interface mn1mar1 is created. However, the same process would be + repeated if more P-MAARs were involved. In order to keep the prefix + anchored at MAAR1 reachable, a tunnel between MAAR1 and MAAR2 is + established and the routing is modified accordingly. The PBU/PBA + signaling is used to set up the bidirectional tunnel between MAAR1 + and MAAR2, and it might also be used to convey the information about + the prefix(es) anchored at MAAR1 and the addresses of the associated + DLIF (i.e., mn1mar1) to MAAR2. + + +------------------------------------------+ +----------------------+ + | MAAR1 | | MAAR2 | + |+----------------------------------------+| |+--------------------+| + ||+------------------++------------------+|| ||+------------------+|| + |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| + ||||mn3mar1||mn3mar2||||mn2mar1||mn2mar2|||| ||||mn1mar1||mn1mar2|||| + |||| LMAC1 || LMAC2 |||| LMAC3 || LMAC4 |||| |||| LMAC5 || LMAC6 |||| + |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| + ||| LIFs of MN3 || LIFs of MN2 ||| ||| LIFs of MN1 ||| + ||+------------------++------------------+|| ||+------------------+|| + || MAC1 (phy if MAAR1) || || MAC2 (phy if MAAR2)|| + |+----------------------------------------+| |+--------------------+| + +------------------------------------------+ +----------------------+ + x x x + x x x + (o) (o) (o) + | | | + +--+--+ +--+--+ +--+--+ + | MN3 | | MN2 | | MN1 | + +-----+ +-----+ +-----+ + + Figure 6: Distributed Logical Interface Concept + + Figure 6 shows the logical interface concept in more detail. The + figure shows two MAARs and three MNs. MAAR1 is currently serving MN2 + and MN3, while MAAR2 is serving MN1. Note that an S-MAAR always + plays the role of anchoring MAAR for the attached (served) MNs. Each + MAAR has one single physical wireless interface as depicted in this + example. + + As discussed before, each MN always "sees" multiple logical routers + -- one per anchoring MAAR -- independently of its currently S-MAAR. + From the point of view of the MN, these MAARs are portrayed as + different routers, although the MN is physically attached to a single + interface. This is achieved by the S-MAAR configuring different + logical interfaces. MN1 is currently attached to MAAR2 (i.e., MAAR2 + is its S-MAAR) and, therefore, it has configured an IPv6 address from + MAAR2's pool (e.g., prefB::/64). MAAR2 has set up a logical + interface (mn1mar2) on top of its wireless physical interface (phy if + MAAR2), which is used to serve MN1. This interface has a logical MAC + address (LMAC6) that is different from the hardware MAC address + (MAC2) of the physical interface of MAAR2. Over the mn1mar2 + interface, MAAR2 advertises its locally anchored prefix prefB::/64. + Before attaching to MAAR2, MN1 was attached to MAAR1 and configured a + locally anchored address at that MAAR, which is still being used by + MN1 in active communications. MN1 keeps "seeing" an interface + connecting to MAAR1 as if it were directly connected to the two + MAARs. This is achieved by the S-MAAR (MAAR2) configuring an + additional DLIF, mn1mar1, which behaves as the logical interface + configured by MAAR1 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 MAAR that is serving the + MN. The information required by an S-MAAR 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 MAAR may have + several logical interfaces associated with each attached MN and + always has at least one (since an S-MAAR is also an anchoring MAAR + for the attached MN). + + In order to enforce the use of the prefix locally anchored at the + S-MAAR, the RAs sent over those logical interfaces playing the role + of anchoring MAARs (different from the serving one) include a zero + preferred prefix lifetime (and a non-zero valid prefix lifetime, so + the prefix remains valid while being deprecated). The goal is to + deprecate the prefixes delegated by these MAARs (so that they will no + longer be serving the MN). Note that ongoing communications may keep + on using those addresses even if they are deprecated, so this only + affects the establishment of new sessions. + + The DLIF concept also enables the following use case: suppose that + access to a local IP network is provided by a given MAAR (e.g., MAAR1 + in the example shown in Figure 5) 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 MAAR2). This is similar to + the local IP access scenario considered by 3GPP, where a local + gateway node is selected for sessions requiring access to services + provided locally (instead of going through a central gateway). 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 more specific routes, as discussed in + RFC 4191 [RFC4191], when the MN moves to a MAAR different from the + one providing access to the local IP network (MAAR1 in the example). + These routes are advertised through the DLIF where the MAAR is + providing access to the local network (MAAR1 in this example). In + this way, if MN1 moves from MAAR1 to MAAR2, any active session that + MN1 may have with a node on the local network connected to MAAR1 will + survive via the tunnel between MAAR1 and MAAR2. Also, any potential + future connection attempt to the local network will be supported even + though MN1 is no longer attached to MAAR1, so long as a source + address configured from MAAR1 is selected for new connections (see + [RFC6724], rule 5.5). + +4. Message Format + + This section defines extensions to the PMIPv6 [RFC5213] protocol + messages. + +4.1. Proxy Binding Update + + A new flag (D) is included in the PBU to indicate that the PBU is + coming from a MAAR or a CMD and not from a MAG. The rest of the PBU + 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|F|T|B|S|D| Rsrvd | Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . + . Mobility Options . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + DMM Flag (D) + The D flag is set to indicate to the receiver of the message that + the PBU is from a MAAR or a CMD. When an LMA that does not + support the extensions described in this document receives a + message with the D flag set, the PBU in that case MUST NOT be + processed by the LMA, and an error MUST be returned. + + Mobility Options + Variable-length field of such length that the complete Mobility + Header is an integer that is a multiple of 8 octets long. This + field contains zero or more TLV-encoded mobility options. The + encoding and format of the defined options are described in + Section 6.2 of [RFC6275]. The receiving node MUST ignore and skip + any options that it does not understand. + +4.2. Proxy Binding Acknowledgement + + A new flag (D) is included in the PBA to indicate that the sender + supports operating as a MAAR or CMD. The rest of the PBA 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Status |K|R|P|T|B|S|D| | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence # | Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . + . Mobility Options . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + DMM Flag (D) + The D flag is set to indicate that the sender of the message + supports operating as a MAAR or CMD. When a MAG that does not + support the extensions described in this document receives a + message with the D flag set, it MUST ignore the message, and an + error MUST be returned. + + 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 the defined options are described in Section 6.2 of + [RFC6275]. The MAAR MUST ignore and skip any options that it does + not understand. + +4.3. Anchored Prefix Option + + A new Anchored Prefix option is defined for use with the PBU and PBA + messages exchanged between MAARs and CMDs. Therefore, this option + can only appear if the D bit is set in a PBU/PBA. This option is + used for exchanging the MN's prefix anchored at the anchoring MAAR. + 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: + + 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 + 65 + + 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 at the time of publication. 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 in bits of the + IPv6 prefix contained in the option. + + Anchored Prefix + A 16-octet field containing the MN's IPv6 Anchored Prefix. Only + the first Prefix Length bits are valid for the Anchored Prefix + option. The rest of the bits MUST be ignored. + +4.4. Local Prefix Option + + A new Local Prefix option is defined for use with the PBU and PBA + messages exchanged between MAARs or between a MAAR and a CMD. + Therefore, this option can only appear if the D bit is set in a PBU/ + PBA. This option is used for exchanging a prefix of a local network + that is only reachable via the anchoring MAAR. There can be multiple + Local Prefix options present in the message. + + 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 + 66 + + 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 at the time of publication. 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 in bits of the + IPv6 prefix contained in the option. + + Local Prefix + A 16-octet field containing the IPv6 Local Prefix. Only the first + Prefix Length bits are valid for the IPv6 Local Prefix. The rest + of the bits MUST be ignored. + +4.5. Previous MAAR Option + + This new option is defined for use with the PBA messages exchanged by + the CMD to a MAAR. This option is used to notify the S-MAAR about + the P-MAAR's global address and the prefix anchored to it. There can + be multiple Previous MAAR options present in the message. + + The Previous MAAR 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Previous MAAR + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Home Network Prefix + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + 67 + + 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 34. + + Reserved + This field is unused at the time of publication. 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 in bits of the + IPv6 prefix contained in the option. + + Previous MAAR + A 16-octet field containing the P-MAAR's IPv6 global address. + + Home Network Prefix + A 16-octet field containing the MN's IPv6 Home Network Prefix. + Only the first Prefix Length bits are valid for the MN's IPv6 Home + Network Prefix. The rest of the bits MUST be ignored. + +4.6. Serving MAAR Option + + This new option is defined for use with the PBU message exchanged + between the CMD and a P-MAAR. This option is used to notify the + P-MAAR about the current S-MAAR's global address. Its format is as + follows: + + The Serving MAAR 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + S-MAAR's Address + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + 68 + + 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. + + Serving MAAR + A 16-octet field containing the S-MAAR's IPv6 global address. + +4.7. DLIF Link-Local Address Option + + A new DLIF Link-Local Address option is defined for use with the PBA + message exchanged between MAARs and between a MAAR and a CMD. This + option is used for exchanging the link-local address of the DLIF to + be configured on the S-MAAR so it resembles the DLIF configured on + the P-MAAR. + + 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 + 69 + + 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 16-octet field containing the link-local address of the logical + interface. + +4.8. DLIF Link-Layer Address Option + + A new DLIF Link-Layer Address option is defined for use with the PBA + message exchanged between MAARs and between a MAAR and a CMD. This + option is used for exchanging the link-layer address of the DLIF to + be configured on the S-MAAR so it resembles the DLIF configured on + the P-MAAR. + + 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 the mobility option alignment requirements + specified in [RFC6275]. + + 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 + 70 + + Length + 8-bit unsigned integer indicating the length of the option in + octets, excluding the type and length fields. + + Reserved + This field is unused at the time of publication. 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 S-MAAR. + + The content and format of this field (including octet 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. IANA Considerations + + This document defines six new mobility options: Anchored Prefix, + Local Prefix, Previous MAAR, Serving MAAR, DLIF Link-Local Address, + and DLIF Link-Layer Address. IANA has assigned Type values for these + options from the same numbering space as allocated for the other + mobility options in the "Mobility Options" registry defined in + http://www.iana.org/assignments/mobility-parameters. + + This document reserves a new flag (D) with a value of 0x0010 in the + "Binding Update Flags" registry and a new flag (D) with a value of + 0x02 in the "Binding Acknowledgment Flags" of the "Mobile IPv6 + parameters" registry (http://www.iana.org/assignments/mobility- + parameters). + +6. Security Considerations + + The protocol extensions defined in this document share the same + security concerns of PMIPv6 [RFC5213]. It is recommended that the + signaling messages, PBU and PBA, exchanged between the MAARs be + protected using IPsec, specifically by using the established security + association between them. This essentially eliminates the threats + related to the impersonation of a MAAR. + + When the CMD acts as a PBU/PBA relay, the CMD may act as a relay of a + single PBU to multiple P-MAARs. In situations with many fast + handovers (e.g., with vehicular networks), multiple previous (e.g., + k) MAARs may exist. In this situation, the CMD creates k outgoing + packets from a single incoming packet. This bears a certain + amplification risk. The CMD MUST use a pacing approach in the + outgoing queue to cap the output traffic (i.e., the rate of PBUs + sent) to limit this amplification risk. + + When the CMD acts as a MAAR locator, mobility signaling (PBAs) is + exchanged between P-MAARs and the current S-MAAR. Hence, security + associations are REQUIRED to exist between the involved MAARs (in + addition to the ones needed with the CMD). + + Since de-registration is performed by timeout, measures SHOULD be + implemented to minimize the risks associated with continued resource + consumption (DoS attacks), e.g., imposing a limit on the number of + P-MAARs associated with a given MN. + + The CMD and the participating MAARs MUST be trusted parties + authorized perform all operations relevant to their role. + + There are some privacy considerations to consider. While the + involved parties trust each other, the signaling involves disclosing + information about the previous locations visited by each MN, as well + as the active prefixes they are using at a given point of time. + Therefore, mechanisms MUST be in place to ensure that MAARs and CMDs + do not disclose this information to other parties or use it for other + ends than providing the distributed mobility support specified in + this document. + +7. References + +7.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, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and + More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, + November 2005, <https://www.rfc-editor.org/info/rfc4191>. + + [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, + <https://www.rfc-editor.org/info/rfc4861>. + + [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., + Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", + RFC 5213, DOI 10.17487/RFC5213, August 2008, + <https://www.rfc-editor.org/info/rfc5213>. + + [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility + Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July + 2011, <https://www.rfc-editor.org/info/rfc6275>. + + [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, + <https://www.rfc-editor.org/info/rfc7333>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +7.2. Informative References + + [DISTRIBUTED-ANCHORING] + Bernardos, C. and J. Zuniga, "PMIPv6-based distributed + anchoring", Work in Progress, Internet-Draft, draft- + bernardos-dmm-distributed-anchoring-09, 29 May 2017, + <https://tools.ietf.org/html/draft-bernardos-dmm- + distributed-anchoring-09>. + + [DMM-PMIP] Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based + solution for Distributed Mobility Management", Work in + Progress, Internet-Draft, draft-bernardos-dmm-pmip-09, 8 + September 2017, + <https://tools.ietf.org/html/draft-bernardos-dmm-pmip-09>. + + [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, + "Default Address Selection for Internet Protocol Version 6 + (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, + <https://www.rfc-editor.org/info/rfc6724>. + + [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, + <https://www.rfc-editor.org/info/rfc7429>. + + [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, + Ed., "Bidirectional Forwarding Detection (BFD) Multipoint + Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, + <https://www.rfc-editor.org/info/rfc8563>. + +Acknowledgements + + The authors would like to thank Dirk von Hugo, John Kaippallimalil, + Ines Robles, Joerg Ott, Carlos Pignataro, Vincent Roca, Mirja + Kühlewind, Éric Vyncke, Adam Roach, Benjamin Kaduk, and Roman Danyliw + for the comments on this document. The authors would also like to + thank Marco Liebsch, Dirk von Hugo, Alex Petrescu, Daniel Corujo, + Akbar Rahman, Danny Moses, Xinpeng Wei, and Satoru Matsushima for + their comments and discussion on the documents + [DISTRIBUTED-ANCHORING] and [DMM-PMIP], on which the present document + is based. + + The authors would also like to thank Lyle Bertz and Danny Moses for + their in-depth review of this document and their very valuable + comments and suggestions. + +Authors' Addresses + + Carlos J. Bernardos + Universidad Carlos III de Madrid + Av. Universidad, 30 + 28911 Leganes Madrid + Spain + + Phone: +34 91624 6236 + Email: cjbc@it.uc3m.es + URI: http://www.it.uc3m.es/cjbc/ + + + Antonio de la Oliva + Universidad Carlos III de Madrid + Av. Universidad, 30 + 28911 Leganes Madrid + Spain + + Phone: +34 91624 8803 + Email: aoliva@it.uc3m.es + URI: http://www.it.uc3m.es/aoliva/ + + + Fabio Giust + Athonet S.r.l. + via Ca' del Luogo 6/8 + 36050 Bolzano Vicentino (VI) + Italy + + Email: fabio.giust.research@gmail.com + + + Juan Carlos Zúñiga + SIGFOX + 425 rue Jean Rostand + 31670 Labege + France + + Email: j.c.zuniga@ieee.org + URI: http://www.sigfox.com/ + + + Alain Mourad + InterDigital Europe + + Email: Alain.Mourad@InterDigital.com + URI: http://www.InterDigital.com/ |