[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-melia-netext-logical-interface-support) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 RFC 7847

NETEXT WG                                                  T. Melia, Ed.
Internet-Draft                                            Alcatel-Lucent
Intended status: Informational                        S. Gundavelli, Ed.
Expires: April 21, 2014                                            Cisco
                                                        October 18, 2013


           Logical Interface Support for multi-mode IP Hosts
             draft-ietf-netext-logical-interface-support-08

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.
   The Logical Interface support is required on the mobile node
   operating in 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 Logical Interface construct and
   the specifics on how the 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 context with various
   mobility management features.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at 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 April 21, 2014.

Copyright Notice

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



Melia & Gundavelli       Expires April 21, 2014                 [Page 1]


Internet-Draft          Logical Interface Support           October 2013


   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.  Hiding Link-layer Technologies - Approaches and
       Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Link-layer Abstraction - Approaches  . . . . . . . . . . .  5
     3.2.  Applicability Statement  . . . . . . . . . . . . . . . . .  6
       3.2.1.  Link layer support . . . . . . . . . . . . . . . . . .  6
       3.2.2.  Logical Interface  . . . . . . . . . . . . . . . . . .  6

   4.  Technology Use cases . . . . . . . . . . . . . . . . . . . . .  8

   5.  Logical Interface Functional Details . . . . . . . . . . . . .  9
     5.1.  Configuration of a Logical Interface . . . . . . . . . . . 10
     5.2.  Logical Interface Forwarding Conceptual Data Structures  . 10

   6.  Logical Interface Use-cases in Proxy Mobile IPv6 . . . . . . . 12
     6.1.  Multihoming Support  . . . . . . . . . . . . . . . . . . . 12
     6.2.  Inter-Technology Handoff Support . . . . . . . . . . . . . 13
     6.3.  Flow Mobility Support  . . . . . . . . . . . . . . . . . . 14

   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15

   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16

   9.  Authors  . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17

   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     11.2. Informative References . . . . . . . . . . . . . . . . . . 18

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19



Melia & Gundavelli       Expires April 21, 2014                 [Page 2]


Internet-Draft          Logical Interface Support           October 2013


1.  Introduction

   Proxy Mobile IPv6 [RFC5213] is a network-based mobility protocol.
   Some of the key goals of the protocol include support for
   multihoming, inter-technology handoffs and flow mobility support.
   The base protocol features specified in [RFC5213] and [RFC5844] allow
   the mobile node to attach to the network using multiple interfaces
   (simultaneously or sequentially), or to perform handoff between
   different interfaces of the mobile node.  However, for supporting
   these features, the mobile node is required to be activated with
   specific software configuration that allows the mobile node to either
   perform inter-technology handoffs between different interfaces,
   attach to the network using multiple interfaces, or perform flow
   movement from one access technology to another.  This document
   analyzes from the mobile node's perspective a specific approach that
   allows the mobile node to leverage these mobility features.
   Specifically, it explores the use of the Logical Interface support, a
   semantic available on most operating systems.

   A Logical Interface is a construct internal to the operating system.
   It is an approach where a logical link-layer implementation hides a
   variety of physical interfaces from the IP stack.  This semantic has
   been used on a variety of operating systems to implement applications
   such as Mobile IP clients [RFC6275] and IPsec VPN clients [RFC4301].

   In the context of an access infrastructure providing network network-
   based mobility management services across a variety of access
   technologies, as provided by a Proxy Mobile IPv6 domain [RFC5213], a
   logical interface can be used to afford inter-technology handover,
   multihoming, and/or flow mobility without requiring from the mobile
   node IP stack specific support to that effect.

   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 logical interface and network elements in the Proxy
   Mobile IPv6 domain when supporting the aforementioned mobility
   management features.  It also analyzes the issues involved with this
   approach and characterizes the contexts in which such usage is
   appropriate.












Melia & Gundavelli       Expires April 21, 2014                 [Page 3]


Internet-Draft          Logical Interface Support           October 2013


2.  Terminology

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

   PIF  (Physical Interface) - a network interface card attached to an
      an host providing network connectivity (e.g. an Ethernet card, a
      WLAN card, an LTE interface).

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

   Sub-If  (Sub Interface) - a physical interface that is part of a
      logical interface construct.  For example, a logical interface may
      have been created 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.


























Melia & Gundavelli       Expires April 21, 2014                 [Page 4]


Internet-Draft          Logical Interface Support           October 2013


3.  Hiding Link-layer Technologies - Approaches and Applicability

   There are several techniques/mechanisms that allow hiding access
   technology changes or movement from host IP layer.  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 in a Proxy
   Mobile IPv6 domain [RFC5213].

3.1.  Link-layer Abstraction - Approaches

   The following generic mechanisms can hide access technology changes
   from 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 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 MAC layer
      takes care of the mobility, making the media change invisible to
      the upper layers.  Another example is IEEE 802.3, that supports
      changing the rate from 10Mbps to 100Mbps and to 1000Mbps.  Another
      example is the situation in the 3GPP Evolved Packet
      System[TS23401] where a UE can perform inter-access handovers
      between three different access technologies (2G GERAN, 3G UTRAN,
      and 4G E-UTRAN) that are invisible to the IP layer at the UE.

   o  A logical interface denotes a mechanism that that logically group/
      bond 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 to 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 based on a combination of
      user preferences on one hand, and operator preferences such as
      those provisionned by the Access Network Discovery and Selection
      Function (ANDSF) [TS23402] on the other hand.






Melia & Gundavelli       Expires April 21, 2014                 [Page 5]


Internet-Draft          Logical Interface Support           October 2013


3.2.  Applicability Statement

   We now focus on the applicability of the above solutions against the
   following requirements:

   o  multi technology support

   o  sequential vs. simultaneous access

3.2.1.  Link layer support

   Link layer mobility support applies to cases when 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 to 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.

3.2.2.  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 to hide inter-access
   technology handovers or application flow handovers 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 MAG and LMA) to deal with logical
   interface, instead to IP interfaces as current RFC5213 does.  RFC5213
   assumes that each physical interface capable of attaching to a MAG is



Melia & Gundavelli       Expires April 21, 2014                 [Page 6]


Internet-Draft          Logical Interface Support           October 2013


   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 multi technology and the sequential vs: simultaneous access
   support.













































Melia & Gundavelli       Expires April 21, 2014                 [Page 7]


Internet-Draft          Logical Interface Support           October 2013


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 any
   of the available devices 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 to 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, 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 IPCP and IPv6CP protocol [RFC5072].
   In this case the PPP interface does not have any L2 address assigned.
   In some other implementations the wireless modem is presented to the
   IP layer as a virtual Ethernet interface.




























Melia & Gundavelli       Expires April 21, 2014                 [Page 8]


Internet-Draft          Logical Interface Support           October 2013


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.  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
   bound.  However, the Logical interface has some special properties
   which are essential for enabling inter-technology handover and flow-
   mobility features.  Following are those properties:



Melia & Gundavelli       Expires April 21, 2014                 [Page 9]


Internet-Draft          Logical Interface Support           October 2013


   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-interface 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 turns decide
   which physical interface is to be used to transmit packets.

5.2.  Logical Interface Forwarding Conceptual Data Structures

   The logical interface maintains the list of sub-interfaces that are
   part of the logical interface.  This conceptual data strucure is
   called as the LIF Table.  The logical interface also maintains the
   list of flows associated with a given sub-interface and this
   conceptual data structure is called as the PIF Table.  Both of these
   data structures have to be associated with a logical interface, and
   are depicted in Figure 2







Melia & Gundavelli       Expires April 21, 2014                [Page 10]


Internet-Draft          Logical Interface Support           October 2013


      LIF TABLE                           FLOW table
    +===============================+   +=============================+
    | PIF_ID | FLOW RoutingPolicies |   | FLOW ID | Physical_Intf_Id  |
    |        | Link Status          |   +-----------------------------+
    +-------------------------------|   | FLOW_ID | Physical_Intf_Id  |
    | PIF_ID | FLOW RoutingPolicies |   +=============================+
    |        | Link Status          |   + ....    | ....              |
    +-------------------------------+   +=============================+
    | ....   | ....                 |
    +===============================+


                                 Figure 2

   The LIF table maintains the mapping between the LIF and each PIF
   associated to the LIF (refer to property #3, Figure 1).  For each PIF
   entry the table should store the associated Routing Policies, and the
   Link Status of the PIF (e.g. active, not active).  The method by
   which the Routing Policies are configured on the host is out of scope
   for this document.

   The FLOW table allows the logical interface to properly route each IP
   flow over the right 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 than 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 PIF_ID parameter 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       Expires April 21, 2014                [Page 11]


Internet-Draft          Logical Interface Support           October 2013


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

   A mobile node with multiple interfaces can attach simultaneously to
   the Proxy Mobile IPv6 domain.  If the host is configured to use
   Logical interface over the physical interfaces through which it is
   attached, following are the related considerations.


                                         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 3: Multihoming Support





Melia & Gundavelli       Expires April 21, 2014                [Page 12]


Internet-Draft          Logical Interface Support           October 2013


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
   retaining the same address configuration on its attached interface.
   The protocol enables a mobile node to achieve address continuity
   during handoffs.  If the host is configured to use 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 4: Inter-Technology Handoff Support

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





Melia & Gundavelli       Expires April 21, 2014                [Page 13]


Internet-Draft          Logical Interface Support           October 2013


   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

   For supporting flow mobility support, there is a need to support
   vertical handoff scenarios such as transferring a subset of
   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 on which is the best MAG that
   should 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.






























Melia & Gundavelli       Expires April 21, 2014                [Page 14]


Internet-Draft          Logical Interface Support           October 2013


7.  IANA Considerations

   This specification does not require any IANA Actions.
















































Melia & Gundavelli       Expires April 21, 2014                [Page 15]


Internet-Draft          Logical Interface Support           October 2013


8.  Security Considerations

   This specification explains the operational details of 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.













































Melia & Gundavelli       Expires April 21, 2014                [Page 16]


Internet-Draft          Logical Interface Support           October 2013


9.  Authors

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

   Carlos Jesus Bernardos Cano

      cjbc@it.uc3m.es

   Antonio De la Oliva

      aoliva@it.uc3m.es

   Yong-Geun Hong

      yonggeun.hong@gmail.com

   Kent Leung

      kleung@cisco.com

   Tran Minh Trung

      trungtm2909@gmail.com

   Hidetoshi Yokota

      yokota@kddilabs.jp

   Juan Carlos Zuniga

      JuanCarlos.Zuniga@InterDigital.com

   Julien Laganier

      jlaganier@JUNIPER.NET


10.  Acknowledgements

   The authors would like to acknowledge prior discussions on this topic
   in NETLMM and NETEXT working groups.  The authors would also like to
   thank Joo-Sang Youn, Pierrick Seite, Rajeev Koodli, Basavaraj Patil,
   Peter McCann, and Julien Laganier for all the discussions on this
   topic.


11.  References



Melia & Gundavelli       Expires April 21, 2014                [Page 17]


Internet-Draft          Logical Interface Support           October 2013


11.1.  Normative References

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", RFC 5844, May 2010.

11.2.  Informative References

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC5072]  Varada, S., Haskins, D., and E. Allen, "IP Version 6 over
              PPP", RFC 5072, September 2007.

   [RFC5677]  Melia, T., Bajko, G., Das, S., Golmie, N., and JC. Zuniga,
              "IEEE 802.21 Mobility Services Framework Design (MSFD)",
              RFC 5677, December 2009.

   [RFC6085]  Gundavelli, S., Townsley, M., Troan, O., and W. Dec,
              "Address Mapping of IPv6 Multicast Packets on Ethernet",
              RFC 6085, January 2011.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

   [RFC6418]  Blanchet, M. and P. Seite, "Multiple Interfaces and
              Provisioning Domains Problem Statement", RFC 6418,
              November 2011.

   [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.", 2009.

   [TS23402]  "3rd Generation Partnership Project; Technical



Melia & Gundavelli       Expires April 21, 2014                [Page 18]


Internet-Draft          Logical Interface Support           October 2013


              Specification Group Services and System Aspects;
              Architecture Enhancements for non-3GPP Accesses.", 2009.


Authors' Addresses

   Telemaco Melia (editor)
   Alcatel-Lucent
   Route de Villejust
   Nozay  91620
   France

   Email: telemaco.melia@alcatel-lucent.com


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

   Email: sgundave@cisco.com





























Melia & Gundavelli       Expires April 21, 2014                [Page 19]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/