DMM Working Group                                          CJ. Bernardos
Internet-Draft                                                      UC3M
Intended status: Standards Track                              JC. Zuniga
Expires: November 30, 2017                                        SIGFOX
                                                            May 29, 2017


                   PMIPv6-based distributed anchoring
              draft-bernardos-dmm-distributed-anchoring-09

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 November 30, 2017               [Page 1]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


   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 November 30, 2017.

Copyright Notice

   Copyright (c) 2017 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 November 30, 2017               [Page 2]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


   Appendix A.  Comparison with Requirement document . . . . . . . .  22
     A.1.  Distributed mobility management . . . . . . . . . . . . .  23
     A.2.  Bypassable network-layer mobility           support for
           each application           session  . . . . . . . . . . .  23
     A.3.  IPv6 deployment . . . . . . . . . . . . . . . . . . . . .  23
     A.4.  Existing mobility protocols . . . . . . . . . . . . . . .  24
     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 . . . . . . . . . . . . . . . . . . . . . . . .  25
   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 [I-D.ietf-dmm-distributed-mobility-anchoring]
   at different D-GWs, by introducing the concept of Distributed Logical



Bernardos & Zuniga      Expires November 30, 2017               [Page 3]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


   Interface (DLIF).  The document also 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 November 30, 2017               [Page 4]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


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 November 30, 2017               [Page 5]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


      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 November 30, 2017               [Page 6]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


   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 November 30, 2017               [Page 7]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


   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 November 30, 2017               [Page 8]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


   +------------------------------------------+ +----------------------+
   |                   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 November 30, 2017               [Page 9]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


   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 November 30, 2017              [Page 10]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


   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 November 30, 2017              [Page 11]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


       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 November 30, 2017              [Page 12]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


           +-----+      +-------+      +-------+      +-------------+
           | 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 November 30, 2017              [Page 13]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


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 November 30, 2017              [Page 14]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


   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 November 30, 2017              [Page 15]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


   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 November 30, 2017              [Page 16]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


   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 November 30, 2017              [Page 17]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


   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 November 30, 2017              [Page 18]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


        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 November 30, 2017              [Page 19]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


   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 November 30, 2017              [Page 20]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


   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,
              <http://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, <http://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,
              <http://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,
              <http://www.rfc-editor.org/info/rfc5213>.



Bernardos & Zuniga      Expires November 30, 2017              [Page 21]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
              2011, <http://www.rfc-editor.org/info/rfc6275>.

8.2.  Informative References

   [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.

   [I-D.bernardos-dmm-pmip]
              Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based
              solution for Distributed Mobility Management", draft-
              bernardos-dmm-pmip-08 (work in progress), March 2017.

   [I-D.ietf-dmm-distributed-mobility-anchoring]
              Chan, A., Wei, X., Lee, J., Jeon, S., Petrescu, A., and F.
              Templin, "Distributed Mobility Anchoring", draft-ietf-dmm-
              distributed-mobility-anchoring-05 (work in progress), May
              2017.

   [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,
              <http://www.rfc-editor.org/info/rfc7333>.

   [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,
              <http://www.rfc-editor.org/info/rfc7429>.

Appendix A.  Comparison with Requirement document

   In this section we descrbe how our solution addresses the DMM
   requirements listed in [RFC7333].








Bernardos & Zuniga      Expires November 30, 2017              [Page 22]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


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
   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,




Bernardos & Zuniga      Expires November 30, 2017              [Page 23]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


   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."

   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




Bernardos & Zuniga      Expires November 30, 2017              [Page 24]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


   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."

   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).




Bernardos & Zuniga      Expires November 30, 2017              [Page 25]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


   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.

   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/



Bernardos & Zuniga      Expires November 30, 2017              [Page 26]


Internet-Draft        PMIPv6 distributed anchoring              May 2017


   Juan Carlos Zuniga
   SIGFOX
   425 rue Jean Rostand
   Labege  31670
   France

   Email: j.c.zuniga@ieee.org
   URI:   http://www.sigfox.com/











































Bernardos & Zuniga      Expires November 30, 2017              [Page 27]