--- 1/draft-ietf-dmm-pmipv6-dlif-04.txt 2019-11-02 05:13:11.906083797 -0700 +++ 2/draft-ietf-dmm-pmipv6-dlif-05.txt 2019-11-02 05:13:11.978085619 -0700 @@ -1,24 +1,24 @@ DMM Working Group CJ. Bernardos Internet-Draft A. de la Oliva Intended status: Experimental UC3M -Expires: August 2, 2019 F. Giust +Expires: May 5, 2020 F. Giust Athonet JC. Zuniga SIGFOX A. Mourad InterDigital - January 29, 2019 + November 2, 2019 Proxy Mobile IPv6 extensions for Distributed Mobility Management - draft-ietf-dmm-pmipv6-dlif-04 + draft-ietf-dmm-pmipv6-dlif-05 Abstract Distributed Mobility Management solutions allow for setting up networks so that traffic is distributed in an optimal way and does not rely on centrally 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 @@ -29,39 +29,41 @@ mobility anchor and access router). The mobility anchor and access router is an enhanced access router which 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 simultaneously anchoring several flows at different distributed gateways. 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]. + "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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 https://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 August 2, 2019. + This Internet-Draft will expire on May 5, 2020. Copyright Notice Copyright (c) 2019 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 @@ -74,49 +76,49 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. PMIPv6 DMM extensions . . . . . . . . . . . . . . . . . . . . 5 3.1. Initial registration . . . . . . . . . . . . . . . . . . 7 3.2. The CMD as PBU/PBA relay . . . . . . . . . . . . . . . . 8 3.3. The CMD as MAAR locator . . . . . . . . . . . . . . . . . 11 3.4. The CMD as MAAR proxy . . . . . . . . . . . . . . . . . . 12 3.5. De-registration . . . . . . . . . . . . . . . . . . . . . 13 - 3.6. The Distributed Logical Interface (DLIF) concept . . . . 13 - 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 17 - 4.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . 17 - 4.2. Proxy Binding Acknowledgment . . . . . . . . . . . . . . 18 + 3.6. The Distributed Logical Interface (DLIF) concept . . . . 14 + 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 18 + 4.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . 18 + 4.2. Proxy Binding Acknowledgment . . . . . . . . . . . . . . 19 4.3. Anchored Prefix Option . . . . . . . . . . . . . . . . . 19 4.4. Local Prefix Option . . . . . . . . . . . . . . . . . . . 20 - 4.5. Previous MAAR Option . . . . . . . . . . . . . . . . . . 21 - 4.6. Serving MAAR Option . . . . . . . . . . . . . . . . . . . 22 + 4.5. Previous MAAR Option . . . . . . . . . . . . . . . . . . 22 + 4.6. Serving MAAR Option . . . . . . . . . . . . . . . . . . . 23 4.7. DLIF Link-local Address Option . . . . . . . . . . . . . 23 4.8. DLIF Link-layer Address Option . . . . . . . . . . . . . 24 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 - 8.2. Informative References . . . . . . . . . . . . . . . . . 26 - Appendix A. Comparison with Requirement document . . . . . . . . 26 - A.1. Distributed mobility management . . . . . . . . . . . . . 27 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 26 + 8.2. Informative References . . . . . . . . . . . . . . . . . 27 + Appendix A. Comparison with Requirement document . . . . . . . . 28 + A.1. Distributed mobility management . . . . . . . . . . . . . 28 A.2. Bypassable network-layer mobility support for each - application session . . . . . . . . . . . . . . . . . . . 27 - A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 27 - A.4. Existing mobility protocols . . . . . . . . . . . . . . . 28 + application session . . . . . . . . . . . . . . . . . . . 28 + A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 29 + A.4. Existing mobility protocols . . . . . . . . . . . . . . . 29 A.5. Coexistence with deployed networks/hosts and operability - across different networks . . . . . . . . . . . . . . . . 28 - A.6. Operation and management considerations . . . . . . . . . 28 - A.7. Security considerations . . . . . . . . . . . . . . . . . 28 - A.8. Multicast considerations . . . . . . . . . . . . . . . . 29 - Appendix B. Implementation experience . . . . . . . . . . . . . 29 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 + across different networks . . . . . . . . . . . . . . . . 29 + A.6. Operation and management considerations . . . . . . . . . 30 + A.7. Security considerations . . . . . . . . . . . . . . . . . 30 + A.8. Multicast considerations . . . . . . . . . . . . . . . . 30 + Appendix B. Implementation experience . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 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). Current IP mobility solutions, standardized with the names of Mobile IPv6 [RFC6275], or Proxy Mobile IPv6 (PMIPv6) [RFC5213], just to cite the two most relevant examples, offer mobility support at the cost of @@ -271,25 +273,25 @@ o The CMD is only a MAAR locator; o The CMD is a PBU/PBA proxy. This solution can be categorized under Model-1: Split Home Anchor Mode in [I-D.ietf-dmm-deployment-models]. As another note, the solution described in this document allows performing per-prefix anchoring decisions, to support e.g., some flows to be anchored 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 [I-D.ietf-dmm-ondemand-mobility]. 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. + 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 a 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). @@ -451,20 +453,31 @@ 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 to 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 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. When aggregating and relaying PBAs, + the CMD SHOULD make use of the timeout also to deal with missing PBAs + (to retransmit PBUs). The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD + be used for configuring the retransmission timer. + + When there are multiple previous 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 originated from the + CMD, albeit to different targets. Pacing mechanisms MAY 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 signal directly 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 P-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 S-MAAR option), and, besides sending a PBA to the CMD, it also sends a PBA to the @@ -510,21 +523,21 @@ 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 also in this case the P-MAAR option. In parallel, a PBU is sent by the CMD to the P-MAARs containing the S-MAAR option, to notify them about the new MN's location, so 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 is concluded and the information are + to indicate that the operation is concluded and the information is updated in all network nodes. This procedure is obtained from the first one re-arranging 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 * +---+ * @@ -576,25 +589,25 @@ o Previous 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 re- newing the session, if the MN is still connected to the domain. 3.6. 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 MAARs, and how to influence on the mobile - node's selection process of its source IPv6 address for a new flow, - without requiring special support from the mobile node's IP stack. - This document defines the Distributed Logical Interface (DLIF), which - is a software construct that allows to easily hide the change of + anchored at different MAARs, and how to influence the mobile node's + selection process of its source IPv6 address for a new flow, without + requiring special support from the mobile node's IP stack. This + document defines the Distributed Logical Interface (DLIF), which is a + software construct that allows to easily hide the change of associated anchors from the mobile node. +---------------------------------------------------+ ( Operator's ) ( core ) +---------------------------------------------------+ | | +---------------+ tunnel +---------------+ | IP stack |===============| IP stack | +---------------+ +-------+-------+ @@ -1103,40 +1119,60 @@ logical interface to be configured on the S-MAAR. 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. IANA Considerations - This document defines new mobility options that require IANA actions: - IANA-1 to IANA-6. + This document defines six new mobility options that need to be + registered in the Mobility Options registry on the Mobile IPv6 + parameters registry. The required IANA actions are marked as IANA-1 + to IANA-6. 6. 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 MAARs are protected using IPsec 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 previous MAARs. In situations of many fast + handovers (e.g., with vehicular networks), there may exist multiple + previous (e.g., k) MAARs exist. In this situation, the CMD creates k + outgoing packets from a single incoming packet. This bears a certain + amplification risk. The CMD SHOULD use a pacing approach to limit + this amplification risk. + + When the CMD acts as MAAR locator, mobility signaling (PBAs) is + exchanged between P-MAARs and current S-MAAR. This requires security + associations to exist between the involved MAARs (in addition to the + ones needed with the CMD). + + Since deregistration is performed by timeout, measures SHOULD be + implemented to minimize the risks associated to continued resource + consumption (DoS attacks), e.g., imposing a limit of the number of + P-MAARs associated to a given MN. + 7. Acknowledgments - The authors would like to thank Dirk von Hugo and John Kaippallimalil - 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 + The authors would like to thank Dirk von Hugo, John Kaippallimalil, + Ines Robles and Joerg Ott 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 [I-D.bernardos-dmm-distributed-anchoring] and [I-D.bernardos-dmm-pmip] on which the present document is based. The authors would also like to thank Lyle Bertz and Danny Moses for their in-deep review of this document and their very valuable comments and suggestions. 8. References 8.1. Normative References @@ -1157,53 +1193,57 @@ [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + 8.2. Informative References [I-D.bernardos-dmm-distributed-anchoring] Bernardos, C. and J. Zuniga, "PMIPv6-based distributed anchoring", draft-bernardos-dmm-distributed-anchoring-09 (work in progress), May 2017. [I-D.bernardos-dmm-pmip] Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based solution for Distributed Mobility Management", draft- bernardos-dmm-pmip-09 (work in progress), September 2017. [I-D.ietf-dmm-deployment-models] Gundavelli, S. and S. Jeon, "DMM Deployment Models and Architectural Considerations", draft-ietf-dmm-deployment- models-04 (work in progress), May 2018. - [I-D.ietf-dmm-ondemand-mobility] - Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S. - Jeon, "On Demand Mobility Management", draft-ietf-dmm- - ondemand-mobility-15 (work in progress), July 2018. - [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, . + [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, + . + Appendix A. Comparison with Requirement document In this section we describe 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."