diff options
Diffstat (limited to 'doc/rfc/rfc7847.txt')
| -rw-r--r-- | doc/rfc/rfc7847.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc7847.txt b/doc/rfc/rfc7847.txt new file mode 100644 index 0000000..d605cc2 --- /dev/null +++ b/doc/rfc/rfc7847.txt @@ -0,0 +1,899 @@ + + + + + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + |