path: root/doc/rfc/rfc7847.txt

Internet Engineering Task Force (IETF)                     T. Melia, Ed.
Request for Comments: 7847                             Kudelski Security
Category: Informational                               S. Gundavelli, Ed.
ISSN: 2070-1721                                                    Cisco
                                                                May 2016


    Logical-Interface Support for IP Hosts with Multi-Access Support

Abstract

   A logical interface is a software semantic internal to the host
   operating system.  This semantic is available in all popular
   operating systems and is used in various protocol implementations.
   Logical-interface support is required on the mobile node attached to
   a Proxy Mobile IPv6 domain for leveraging various network-based
   mobility management features such as inter-technology handoffs,
   multihoming, and flow mobility support.  This document explains the
   operational details of the logical-interface construct and the
   specifics on how link-layer implementations hide the physical
   interfaces from the IP stack and from the network nodes on the
   attached access networks.  Furthermore, this document identifies the
   applicability of this approach to various link-layer technologies and
   analyzes the issues around it when used in conjunction with various
   mobility management features.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   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 a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7847.










Melia & Gundavelli            Informational                     [Page 1]
^L
RFC 7847                Logical-Interface Support               May 2016


Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Hiding Link-Layer Technologies -- Approaches and
       Applicability . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Link-Layer Abstraction -- Approaches  . . . . . . . . . .   4
     3.2.  Link-Layer Support  . . . . . . . . . . . . . . . . . . .   5
     3.3.  Logical Interface . . . . . . . . . . . . . . . . . . . .   6
   4.  Technology Use Cases  . . . . . . . . . . . . . . . . . . . .   6
   5.  Logical-Interface Functional Details  . . . . . . . . . . . .   7
     5.1.  Configuration of a Logical Interface  . . . . . . . . . .   8
     5.2.  Logical-Interface Conceptual Data Structures  . . . . . .   9
   6.  Logical-Interface Use Cases in Proxy Mobile IPv6  . . . . . .  11
     6.1.  Multihoming Support . . . . . . . . . . . . . . . . . . .  11
     6.2.  Inter-technology Handoff Support  . . . . . . . . . . . .  12
     6.3.  Flow Mobility Support . . . . . . . . . . . . . . . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  15
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16












Melia & Gundavelli            Informational                     [Page 2]
^L
RFC 7847                Logical-Interface Support               May 2016


1.  Introduction

   Proxy Mobile IPv6 (PMIPv6) [RFC5213] is a network-based mobility
   management protocol standardized by IETF.  One of the key goals of
   the PMIPv6 protocol is to enable a mobile node to perform handovers
   across access networks based on different access technologies.  The
   protocol was also designed with the goal to allow a mobile node to
   simultaneously attach to different access networks and perform flow-
   based access selection [RFC7864].  The base protocol features
   specified in [RFC5213] and [RFC5844] have support for these
   capabilities.  However, to support these features, the mobile node is
   required to be enabled with a specific software configuration known
   as logical-interface support.  The logical-interface configuration is
   essential for a mobile node to perform inter-access handovers without
   impacting the IP sessions on the host.

   A logical-interface construct is internal to the operating system.
   It is an approach of interface abstraction, where a logical link-
   layer implementation hides a variety of physical interfaces from the
   IP stack.  This semantic was used on a variety of operating systems
   to implement applications such as Mobile IP client [RFC6275] and
   IPsec VPN client [RFC4301].  Many host operating systems have support
   for some form of such logical-interface construct.  But, there is no
   specification that documents the behavior of these logical interfaces
   or the requirements of a logical interface for supporting the above-
   mentioned mobility management features.  This specification attempts
   to document these aspects.

   The rest of the document provides a functional description of a
   logical interface on the mobile node and the interworking between a
   mobile node using a logical interface and the network elements in the
   Proxy Mobile IPv6 domain.  It also analyzes the issues involved with
   the use of a logical interface and characterizes the contexts in
   which such usage is appropriate.

2.  Terminology

   All the mobility-related terms used in this document are to be
   interpreted as defined in the Proxy Mobile IPv6 specifications
   [RFC5213] and [RFC5844].  In addition, this document uses the
   following terms:

   PIF (Physical Interface):  A network interface module on the host
      that is used for connecting to an access network.  A host
      typically has a number of network interface modules, such as
      Ethernet, Wireless LAN, LTE, etc.  Each of these network
      interfaces can support specific link technology.




Melia & Gundavelli            Informational                     [Page 3]
^L
RFC 7847                Logical-Interface Support               May 2016


   LIF (Logical Interface):  A virtual interface in the IP stack.  A
      logical interface appears to the IP stack just as any other
      physical interface and provides similar semantics with respect to
      packet transmit and receive functions to the upper layers of the
      IP stack.  However, it is only a logical construct and is not a
      representation of an instance of any physical hardware.

   SIF (Sub-Interface):  A physical or logical interface that is part of
      a logical-interface construct.  For example, a logical interface
      may have been created by abstracting two physical interfaces, LTE
      and WLAN.  These physical interfaces, LTE and WLAN, are referred
      to as sub-interfaces of that logical interface.  In some cases, a
      sub-interface can also be another logical interface, such as an
      IPsec tunnel interface.

3.  Hiding Link-Layer Technologies -- Approaches and Applicability

   There are several techniques that allow hiding changes in access
   technology changes from the host layer.  These changes in access
   technology are primarily due to the host's movement between access
   networks.  This section classifies these existing techniques into a
   set of generic approaches, according to their most representative
   characteristics.  Later sections of this document analyze the
   applicability of these solution approaches for supporting features,
   such as inter-technology handovers and IP flow mobility support for a
   mobile node.

3.1.  Link-Layer Abstraction -- Approaches

   The following generic mechanisms can hide access technology changes
   from the host IP layer:

   o  Link-Layer Support -- Certain link-layer technologies are able to
      hide physical media changes from the upper layers.  For example,
      IEEE 802.11 is able to seamlessly change between IEEE 802.11a/b/g
      physical layers.  Also, an 802.11 Station (STA) can move between
      different access points within the same domain without the IP
      stack being aware of the movement.  In this case, the IEEE 802.11
      Media Access Control (MAC) layer takes care of the mobility,
      making the media change invisible to the upper layers.  Another
      example is IEEE 802.3, which supports changing the rate from 10
      Mbps to 100 Mbps and to 1000 Mbps.  Another example is the
      situation in the 3GPP Evolved Packet System [TS23401] where the
      User Equipment (UE) can perform inter-access handovers between
      three different access technologies (2G GSM/EDGE Radio Access
      Network (GERAN), 3G Universal Terrestrial Radio Access Network
      (UTRAN), and 4G Evolved UTRAN (E-UTRAN)) that are invisible to the
      IP layer at the UE.



Melia & Gundavelli            Informational                     [Page 4]
^L
RFC 7847                Logical-Interface Support               May 2016


   o  A logical interface denotes a mechanism that logically groups
      several physical interfaces so they appear to the IP layer as a
      single interface (see Figure 1).  Depending on the type of access
      technologies, it might be possible to use more than one physical
      interface at a time -- such that the node is simultaneously
      attached via different access technologies -- or just perform
      handovers across a variety of physical interfaces.  Controlling
      the way the different access technologies are used (simultaneous,
      sequential attachment, etc.) is not trivial and requires
      additional intelligence and/or configuration within the logical-
      interface implementation.  The configuration is typically handled
      via a connection manager, and it is based on a combination of user
      preferences on one hand and operator preferences such as those
      provisioned by the Access Network Discovery and Selection Function
      (ANDSF) [TS23402] on the other hand.  The IETF Interfaces MIB
      specified in [RFC2863] and the YANG data model for interface
      management specified in [RFC7223] treat a logical interface just
      like any other type of network interface on the host.  This
      essentially makes the logical interface a natural operating system
      construct.

3.2.  Link-Layer Support

   Link-layer mobility support applies to cases in which the same link-
   layer technology is used and mobility can be fully handled at that
   layer.  One example is the case where several 802.11 access points
   are deployed in the same subnet with a common IP-layer configuration
   (DHCP server, default router, etc.).  In this case, the handover
   across access points need not be hidden to the IP layer since the IP-
   layer configuration remains the same after a handover.  This type of
   scenario is applicable to cases when the different points of
   attachment (i.e., access points) belong to the same network domain,
   e.g., enterprise, hotspots from same operator, etc.

   Since this type of link-layer technology does not typically allow for
   simultaneous attachment to different access networks of the same
   technology, the logical interface would not be used to provide
   simultaneous access for purposes of multihoming or flow mobility.
   Instead, the logical interface can be used to provide inter-access
   technology handover between this type of link-layer technology and
   another link-layer technology, e.g., between IEEE 802.11 and IEEE
   802.16.









Melia & Gundavelli            Informational                     [Page 5]
^L
RFC 7847                Logical-Interface Support               May 2016


3.3.  Logical Interface

   The use of a logical interface allows the mobile node to provide a
   single-interface perspective to the IP layer and its upper layers
   (transport and application).  Doing so allows inter-access technology
   handovers or application flow handovers to be hidden across different
   physical interfaces.

   The logical interface may support simultaneous attachment in addition
   to sequential attachment.  It requires additional support at the node
   and the network in order to benefit from simultaneous attachment.
   For example, special mechanisms are required to enable addressing a
   particular interface from the network (e.g., for flow mobility).  In
   particular, extensions to PMIPv6 are required in order to enable the
   network (i.e., the mobile access gateway (MAG) and local mobility
   anchor (LMA)) to deal with the logical interface, instead of using
   extensions to IP interfaces as currently specified in RFC 5213.  RFC
   5213 assumes that each physical interface capable of attaching to a
   MAG is an IP interface, while the logical-interface solution groups
   several physical interfaces under the same IP logical interface.

   It is therefore clear that the logical-interface approach satisfies
   the requirement of multi-access technology and supports both
   sequential and simultaneous access.

4.  Technology Use Cases

   3GPP has defined the Evolved Packet System (EPS) for heterogeneous
   wireless access.  A mobile device equipped with 3GPP and non-3GPP
   wireless technologies can simultaneously or sequentially connect to
   any of the available access networks and receive IP services through
   any of them.  This document focuses on employing a logical interface
   for simultaneous and sequential use of a variety of access
   technologies.

   As mentioned in the previous sections, the logical-interface
   construct is able to hide from the IP layer the specifics of each
   technology in the context of network-based mobility (e.g., in multi-
   access technology networks based on PMIPv6).  The LIF concept can be
   used with at least the following technologies: 3GPP access
   technologies (3G and LTE), IEEE 802.16 access technology, and IEEE
   802.11 access technology.

   In some UE implementations, the wireless connection setup is based on
   creation of a PPP interface between the IP layer and the wireless
   modem that is configured with the IP Control Protocol (IPCP) and IPv6
   Control Protocol (IPv6CP) [RFC5072].  In this case, the PPP interface
   does not have any layer 2 (L2) addresses assigned.  In some other



Melia & Gundavelli            Informational                     [Page 6]
^L
RFC 7847                Logical-Interface Support               May 2016


   implementations, the wireless modem is presented to the IP layer as a
   virtual Ethernet interface.

5.  Logical-Interface Functional Details

   This section identifies the functional details of a logical interface
   and provides some implementation considerations.

   On most operating systems, a network interface is associated with a
   physical device that offers the services for transmitting and
   receiving IP packets from the network.  In some configurations, a
   network interface can also be implemented as a logical interface,
   which does not have the inherent capability to transmit or receive
   packets on a physical medium, but relies on other physical interfaces
   for such services.  An example of such configuration is an IP tunnel
   interface.

   An overview of a logical interface is shown in Figure 1.  The logical
   interface allows heterogeneous attachment while making changes in the
   underlying media transparent to the IP stack.  Simultaneous and
   sequential network attachment procedures are therefore possible,
   enabling inter-technology and flow mobility scenarios.

                                  +----------------------------+
                                  |          TCP/UDP           |
           Session-to-IP    +---->|                            |
           Address Binding  |     +----------------------------+
                            +---->|             IP             |
           IP Address       +---->|                            |
           Binding          |     +----------------------------+
                            +---->|     Logical Interface      |
           Logical-to-      +---->|      IPv4/IPv6 Address     |
           Physical         |     +----------------------------+
           Interface        +---->|  L2  |  L2  |       |  L2  |
           Binding                |(IF#1)|(IF#2)| ..... |(IF#n)|
                                  +------+------+       +------+
                                  |  L1  |  L1  |       |  L1  |
                                  |      |      |       |      |
                                  +------+------+       +------+

              Figure 1: General Overview of Logical Interface

   From the perspective of the IP stack and the applications, a logical
   interface is just another interface.  In fact, the logical interface
   is only visible to the IP and upper layers when enabled.  A host does
   not see any operational difference between a logical and a physical
   interface.  As with physical interfaces, a logical interface is
   represented as a software object to which IP address configuration is



Melia & Gundavelli            Informational                     [Page 7]
^L
RFC 7847                Logical-Interface Support               May 2016


   bound.  However, the logical interface has some special properties
   that are essential for enabling inter-technology handover and flow-
   mobility features.  Following are those properties:

   1.  The logical interface has a relation to a set of physical
       interfaces (sub-interfaces) on the host that it is abstracting.
       These sub-interfaces can be attached or detached from the logical
       interface at any time.  The sub-interfaces attached to a logical
       interface are not visible to the IP and upper layers.

   2.  The logical interface may be attached to multiple access
       technologies.

   3.  The Transmit/Receive functions of the logical interface are
       mapped to the Transmit/Receive services exposed by the sub-
       interfaces.  This mapping is dynamic, and any change is not
       visible to the upper layers of the IP stack.

   4.  The logical interface maintains IP flow information for each of
       its sub-interfaces.  A conceptual data structure is maintained
       for this purpose.  The host may populate this information based
       on tracking each of the sub-interfaces for the active flows.

5.1.  Configuration of a Logical Interface

   A host may be statically configured with the logical-interface
   configuration, or an application such as a connection manager on the
   host may dynamically create it.  Furthermore, the set of sub-
   interfaces that are part of a logical-interface construct may be a
   fixed set or may be kept dynamic, with the sub-interfaces getting
   added or deleted as needed.  The specific details related to these
   configuration aspects are implementation specific and are outside the
   scope of this document.

   The IP layer should be configured with a default router reachable via
   the logical interface.  The default router can be internal to the
   logical interface, i.e., it is a logical router that in turn decides
   which physical interface is to be used to transmit packets.













Melia & Gundavelli            Informational                     [Page 8]
^L
RFC 7847                Logical-Interface Support               May 2016


5.2.  Logical-Interface Conceptual Data Structures

   Every logical interface maintains a list of sub-interfaces that are
   part of that logical-interface construct.  This is a conceptual data
   structure, called the LIF table.  Figure 2 shows an example LIF table
   where logical interface LIF-1 has three sub-interfaces, ETH-0,
   WLAN-0, and LTE-0, and logical interface LIF-2 has two sub-
   interfaces, ETH-1 and WLAN-1.  For each LIF entry, the table should
   store the associated link status and policy associated with that sub-
   interface (e.g., active or not active).  The method by which the
   routing policies are configured on the host is out of scope for this
   document.

   +=======================+========================+==================+
   |   Logical_Interface   |     Sub_Interface      |  Status/Policy   |
   +=======================+========================+==================+
   |       LIF-1           |          ETH-0         |         UP       |
   +=======================+========================+==================+
   |       LIF-1           |          WLAN-0        |         DOWN     |
   +=======================+========================+==================+
   |       LIF-1           |          LTE-0         |         UP       |
   +=======================+========================+==================+
   |       LIF-2           |          ETH-1         |         UP       |
   +=======================+========================+==================+
   |       LIF-2           |          WLAN-1        |         UP       |
   +=======================+========================+==================+

                     Figure 2: Logical-Interface Table

   The logical interface also maintains the list of flows associated
   with a given sub-interface, and this conceptual data structure is
   called the Flow table.  Figure 3 shows an example Flow table, where
   flows FID-1, FID-2, FID-3, FID-4, and FID-5 are associated with sub-
   interfaces ETH-0, WLAN-0, LTE-0, ETH-1, and WLAN-1, respectively.

















Melia & Gundavelli            Informational                     [Page 9]
^L
RFC 7847                Logical-Interface Support               May 2016


            +=======================+========================+
            |       Flow            |     Sub_Interface      |
            +=======================+========================+
            |       FID-1           |          ETH-0         |
            +=======================+========================+
            |       FID-2           |          WLAN-0        |
            +=======================+========================+
            |       FID-3           |          LTE-0         |
            +=======================+========================+
            |       FID-4           |          ETH-1         |
            +=======================+========================+
            |       FID-5           |          WLAN-1        |
            +=======================+========================+

                           Figure 3: Flow Table

   The Flow table allows the logical interface to properly route each IP
   flow over a specific sub-interface.  The logical interface can
   identify the flows arriving on its sub-interfaces and associate them
   to those sub-interfaces.  This approach is similar to reflective QoS
   performed by the IP routers.  For locally generated traffic (e.g.,
   unicast flows), the logical interface should perform interface
   selection based on the Flow Routing Policies.  In case traffic of an
   existing flow is suddenly received from the network on a different
   sub-interface from the one locally stored, the logical interface
   should interpret the event as an explicit flow mobility trigger from
   the network, and it should update the corresponding entry in the Flow
   table.  Similarly, locally generated events from the sub-interfaces
   or configuration updates to the local policy rules can cause updates
   to the table and hence trigger flow mobility.





















Melia & Gundavelli            Informational                    [Page 10]
^L
RFC 7847                Logical-Interface Support               May 2016


6.  Logical-Interface Use Cases in Proxy Mobile IPv6

   This section explains how the logical-interface support on the mobile
   node can be used for enabling some of the Proxy Mobile IPv6 protocol
   features.

6.1.  Multihoming Support

   Figure 4 shows a mobile node with multiple interfaces attached to a
   Proxy Mobile IPv6 domain.  In this scenario, the mobile node is
   configured to use a logical interface over the physical interfaces
   through which it is attached.

                                         LMA Binding Table
                                    +========================+
                           +----+   | HNP   MN-ID  CoA   ATT |
                           |LMA |   +========================+
                           +----+   | HNP-1 MN-1  PCoA-1  5  |
                            //\\    | HNP-1 MN-1  PCoA-2  4  |
                 +---------//--\\-----------+
                (         //    \\           )
                (        //      \\          )
                 +------//--------\\--------+
                       //          \\
               PCoA-1 //            \\ PCoA-2
                   +----+          +----+
            (WLAN) |MAG1|          |MAG2| (3GPP)
                   +----+          +----+
                      \               /
                       \             /
                        \           /
                         \         /
                          \       /
                     +-------+ +-------+
                     | if_1  | | if_2  |
                     |(WLAN) | |(3GPP) |
                     +-------+-+-------+
                     |     Logical     |
                     |    Interface    |
                     |     (HNP-1)     |
                     +-----------------|
                     |       MN        |
                     +-----------------+

                       Figure 4: Multihoming Support






Melia & Gundavelli            Informational                    [Page 11]
^L
RFC 7847                Logical-Interface Support               May 2016


6.2.  Inter-technology Handoff Support

   The Proxy Mobile IPv6 protocol enables a mobile node with multiple
   network interfaces to move between access technologies but still
   retain the same address configuration on its attached interface.
   Figure 5 shows a mobile node performing an inter-technology handoff
   between access networks.  The protocol enables a mobile node to
   achieve address continuity during handoffs.  If the host is
   configured to use a logical interface over the physical interface
   through which it is attached, following are the related
   considerations.

                                           LMA's Binding Table
                                    +==========================+
                           +----+   | HNP   MN-ID  CoA   ATT   |
                           |LMA |   +==========================+
                           +----+   | HNP-1   MN-1  PCoA-1  5  |
                            //\\                   (pCoA-2)(4) <--change
                 +---------//--\\-----------+
                (         //    \\           )
                (        //      \\          )
                 +------//--------\\--------+
                       //          \\
               PCoA-1 //            \\ PCoA-2
                   +----+          +----+
            (WLAN) |MAG1|          |MAG2| (3GPP)
                   +----+          +----+
                      \               /
                       \   Handoff   /
                        \           /
                         \         /
                     +-------+ +-------+
                     | if_1  | | if_2  |
                     |(WLAN) | |(3GPP) |
                     +-------+-+-------+
                     |     Logical     |
                     |    Interface    |
                     |     (HNP-1)     |
                     +-----------------|
                     |       MN        |
                     +-----------------+

                Figure 5: Inter-technology Handoff Support

   o  When the mobile node performs a handoff between if_1 and if_2, the
      change will not be visible to the applications of the mobile node.





Melia & Gundavelli            Informational                    [Page 12]
^L
RFC 7847                Logical-Interface Support               May 2016


   o  The protocol signaling between the network elements will ensure
      the local mobility anchor will switch the forwarding for the
      advertised prefix set from MAG1 to MAG2.

6.3.  Flow Mobility Support

   To support IP flow mobility, there is a need to support vertical
   handoff scenarios such as transferring a subset of a prefix(es)
   (hence the flows associated to it/them) from one interface to
   another.  The mobile node can support this scenario by using the
   logical-interface support.  This scenario is similar to the inter-
   technology handoff scenario defined in Section 6.2; only a subset of
   the prefixes are moved between interfaces.

   Additionally, IP flow mobility in general initiates when the LMA
   decides to move a particular flow from its default path to a
   different one.  The LMA can decide the best MAG to be used to forward
   a particular flow when the flow is initiated (e.g., based on
   application policy profiles) and/or during the lifetime of the flow
   upon receiving a network-based or a mobile-based trigger.  However,
   the specific details on how the LMA can formulate such flow policy is
   outside the scope of this document.

7.  Security Considerations

   This specification explains the operational details of a logical
   interface on an IP host.  The logical-interface implementation on the
   host is not visible to the network and does not require any special
   security considerations.

   Different layer 2 interfaces and the access networks to which they
   are connected have different security properties.  For example, the
   layer 2 network security of a Wireless LAN network operated by an end
   user is in the control of the home user whereas an LTE operator has
   control of the layer 2 security of the LTE access network.  An
   external entity using lawful means, or through other means, obtains
   the security keys from the LTE operator, but the same may not be
   possible in the case of a Wireless LAN network operated by a home
   user.  Therefore, grouping interfaces with such varying security
   properties into one logical interface could have negative
   consequences in some cases.  Such differences, though subtle, are
   entirely hidden by logical interfaces and are unknown to the upper
   layers.








Melia & Gundavelli            Informational                    [Page 13]
^L
RFC 7847                Logical-Interface Support               May 2016


8.  References

8.1.  Normative References

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

   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010,
              <http://www.rfc-editor.org/info/rfc5844>.

8.2.  Informative References

   [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
              MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
              <http://www.rfc-editor.org/info/rfc2863>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <http://www.rfc-editor.org/info/rfc4301>.

   [RFC5072]  Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6
              over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007,
              <http://www.rfc-editor.org/info/rfc5072>.

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

   [RFC7223]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
              <http://www.rfc-editor.org/info/rfc7223>.

   [RFC7864]  Bernardos, CJ., Ed., "Proxy Mobile IPv6 Extensions to
              Support Flow Mobility", RFC 7864, DOI 10.17487/RFC7864,
              May 2016, <http://www.rfc-editor.org/info/rfc7864>.

   [TS23401]  3rd Generation Partnership Project, "Technical
              Specification Group Services and System Aspects; General
              Packet Radio Service (GPRS) enhancements for Evolved
              Universal Terrestrial Radio Access Network (E-UTRAN)
              access", TS 23.401, V13.6.0, March 2016.







Melia & Gundavelli            Informational                    [Page 14]
^L
RFC 7847                Logical-Interface Support               May 2016


   [TS23402]  3rd Generation Partnership Project, "Technical
              Specification Group Services and System Aspects;
              Architecture enhancements for non-3GPP accesses", TS
              23.402, V13.5.0, March 2016.

Acknowledgements

   The authors would like to acknowledge all the discussions on this
   topic in the NETLMM and NETEXT working groups.  The authors would
   also like to thank Joo-Sang Youn, Pierrick Seite, Rajeev Koodli,
   Basavaraj Patil, Peter McCann, Julien Laganier, Maximilian Riegel,
   Georgios Karagian, Stephen Farrell, and Benoit Claise for their input
   to the document.

Contributors

   This document reflects contributions from the following individuals
   (listed in alphabetical order):

   Carlos Jesus Bernardos Cano
   Email: cjbc@it.uc3m.es

   Antonio De la Oliva
   Email: aoliva@it.uc3m.es

   Yong-Geun Hong
   Email: yonggeun.hong@gmail.com

   Kent Leung
   Email: kleung@cisco.com

   Tran Minh Trung
   Email: trungtm2909@gmail.com

   Hidetoshi Yokota
   Email: yokota@kddilabs.jp

   Juan Carlos Zuniga
   Email: JuanCarlos.Zuniga@InterDigital.com












Melia & Gundavelli            Informational                    [Page 15]
^L
RFC 7847                Logical-Interface Support               May 2016


Authors' Addresses

   Telemaco Melia (editor)
   Kudelski Security
   Geneva
   Switzerland

   Email: telemaco.melia@gmail.com


   Sri Gundavelli (editor)
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   United States

   Email: sgundave@cisco.com


































Melia & Gundavelli            Informational                    [Page 16]
^L