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
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
具有多访问支持的IP主机的逻辑接口支持
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.
逻辑接口是主机操作系统内部的软件语义接口。这种语义在所有流行的操作系统中都可用，并在各种协议实现中使用。连接到代理移动IPv6域的移动节点需要逻辑接口支持，以利用各种基于网络的移动性管理功能，如技术间切换、多归属和流移动性支持。本文档解释了逻辑接口构造的操作细节，以及链路层实现如何从IP堆栈和连接的接入网络上的网络节点隐藏物理接口的细节。此外，本文档确定了该方法对各种链路层技术的适用性，并分析了与各种移动性管理功能结合使用时的相关问题。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7847.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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.
代理移动IPv6（PMIPv6）[RFC5213]是IETF标准化的基于网络的移动性管理协议。PMIPv6协议的关键目标之一是使移动节点能够基于不同的接入技术在接入网络上执行切换。该协议的设计目标也是允许移动节点同时连接到不同的接入网络，并执行基于流的接入选择[RFC7864]。[RFC5213]和[RFC5844]中指定的基本协议功能支持这些功能。然而，为了支持这些功能，需要使用称为逻辑接口支持的特定软件配置来启用移动节点。逻辑接口配置对于移动节点在不影响主机上的IP会话的情况下执行接入间切换至关重要。
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.
逻辑接口构造是操作系统内部的。这是一种接口抽象方法，其中逻辑链路层实现将各种物理接口隐藏在IP堆栈中。此语义用于各种操作系统，以实现移动IP客户端[RFC6275]和IPsec VPN客户端[RFC4301]等应用程序。许多主机操作系统都支持某种形式的逻辑接口构造。但是，没有规范记录这些逻辑接口的行为或支持上述移动性管理特性的逻辑接口的要求。本规范试图记录这些方面。
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.
本文档的其余部分提供了移动节点上逻辑接口的功能描述，以及使用逻辑接口的移动节点与代理移动IPv6域中的网络元素之间的互通。它还分析了使用逻辑接口所涉及的问题，并描述了这种用法适用的上下文。
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:
本文件中使用的所有移动相关术语应按照代理移动IPv6规范[RFC5213]和[RFC5844]中的定义进行解释。此外，本文件使用以下术语：
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.
PIF（物理接口）：主机上用于连接接入网络的网络接口模块。主机通常具有多个网络接口模块，如以太网、无线LAN、LTE等。这些网络接口中的每一个都可以支持特定的链路技术。
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.
LIF（逻辑接口）：IP堆栈中的虚拟接口。逻辑接口在IP堆栈中的表现与任何其他物理接口一样，并为IP堆栈的上层提供了与数据包发送和接收功能类似的语义。然而，它只是一个逻辑结构，不是任何物理硬件实例的表示。
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.
SIF（子接口）：作为逻辑接口构造一部分的物理或逻辑接口。例如，逻辑接口可以通过抽象两个物理接口（LTE和WLAN）来创建。这些物理接口LTE和WLAN称为该逻辑接口的子接口。在某些情况下，子接口也可以是另一个逻辑接口，例如IPsec隧道接口。
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.
有几种技术允许从主机层隐藏访问技术更改中的更改。接入技术的这些变化主要是由于主机在接入网络之间的移动。本节根据最具代表性的特点，将这些现有技术分类为一组通用方法。本文档后面部分将分析这些解决方案方法在支持功能方面的适用性，例如技术间切换和移动节点的IP流移动性支持。
The following generic mechanisms can hide access technology changes from the host IP layer:
以下通用机制可以从主机IP层隐藏访问技术更改：
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.
o 链接层支持——某些链接层技术能够隐藏上层对物理介质的更改。例如，IEEE 802.11能够在IEEE 802.11a/b/g物理层之间无缝切换。此外，802.11站（STA）可以在同一域内的不同接入点之间移动，而IP栈不知道该移动。在这种情况下，IEEE 802.11媒体访问控制（MAC）层负责移动性，使上层看不到媒体更改。另一个例子是IEEE 802.3，它支持将速率从10 Mbps更改为100 Mbps和1000 Mbps。另一个例子是3GPP演进分组系统[TS23401]中的情况，其中用户设备（UE）可以在三种不同接入技术（2G GSM/边缘无线接入网（GERAN）、3G通用地面无线接入网（UTRAN）和4G演进UTRAN（E-UTRAN））之间执行接入间切换对UE处的IP层不可见的。
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.
o 逻辑接口表示一种机制，该机制对多个物理接口进行逻辑分组，以便它们在IP层中显示为单个接口（见图1）。根据接入技术的类型，一次可以使用多个物理接口，这样节点就可以通过不同的接入技术同时连接，或者只是在各种物理接口之间执行切换。控制不同访问技术的使用方式（同步、顺序连接等）并不简单，需要在逻辑接口实现中进行额外的智能和/或配置。该配置通常通过连接管理器进行处理，并且它一方面基于用户偏好，另一方面基于诸如接入网络发现和选择功能（ANDSF）[TS23402]提供的操作员偏好的组合。[RFC2863]中规定的IETF接口MIB和[RFC7223]中规定的用于接口管理的YANG数据模型将逻辑接口视为主机上的任何其他类型的网络接口。这本质上使逻辑接口成为一种自然的操作系统结构。
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.
链路层移动性支持适用于使用相同链路层技术且可在该层完全处理移动性的情况。一个例子是，多个802.11接入点部署在具有公共IP层配置（DHCP服务器、默认路由器等）的同一子网中。在这种情况下，接入点之间的切换不需要对IP层隐藏，因为IP层配置在切换后保持不变。这种类型的场景适用于不同连接点（即接入点）属于同一网络域的情况，例如企业、同一运营商的热点等。
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.
由于这种类型的链路层技术通常不允许同时连接到同一技术的不同接入网络，因此逻辑接口将不用于为多归属或流移动性目的提供同时接入。相反，逻辑接口可用于提供这种类型的链路层技术与另一链路层技术（例如，IEEE 802.11和IEEE 802.16之间）之间的接入间技术切换。
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.
逻辑接口的使用允许移动节点向IP层及其上层（传输和应用）提供单一接口透视图。这样做允许跨不同物理接口隐藏接入间技术切换或应用程序流切换。
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.
除了顺序连接之外，逻辑接口还支持同时连接。为了从同步连接中获益，它需要在节点和网络上提供额外的支持。例如，需要特殊机制来实现从网络寻址特定接口（例如，流移动性）。具体而言，需要对PMIPv6进行扩展，以使网络（即，移动接入网关（MAG）和本地移动锚（LMA））能够处理逻辑接口，而不是使用RFC 5213中当前指定的对IP接口的扩展。RFC 5213假设能够连接到MAG的每个物理接口都是IP接口，而逻辑接口解决方案将多个物理接口分组在同一IP逻辑接口下。
It is therefore clear that the logical-interface approach satisfies the requirement of multi-access technology and supports both sequential and simultaneous access.
因此，很明显，逻辑接口方法满足多址技术的要求，并支持顺序和同时访问。
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.
3GPP已经定义了用于异构无线接入的演进分组系统（EPS）。配备有3GPP和非3GPP无线技术的移动设备可以同时或顺序地连接到任何可用接入网络并通过其中任何一个接收IP服务。本文档重点介绍如何使用逻辑接口来同时和顺序使用各种访问技术。
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.
如前几节所述，逻辑接口构造能够在基于网络的移动性的上下文中（例如，在基于PMIPv6的多接入技术网络中）向IP层隐藏每种技术的细节。LIF概念至少可用于以下技术：3GPP接入技术（3G和LTE）、IEEE 802.16接入技术和IEEE 802.11接入技术。
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
在一些UE实现中，无线连接设置基于IP层和无线调制解调器之间的PPP接口的创建，该无线调制解调器配置有IP控制协议（IPCP）和IPv6控制协议（IPv6CP）[RFC5072]。在这种情况下，PPP接口没有分配任何第2层（L2）地址。在其他方面
implementations, the wireless modem is presented to the IP layer as a virtual Ethernet interface.
在实现中，无线调制解调器作为虚拟以太网接口呈现给IP层。
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.
在大多数操作系统上，网络接口与提供从网络发送和接收IP数据包的服务的物理设备相关联。在一些配置中，网络接口也可以实现为逻辑接口，其不具有在物理介质上发送或接收分组的固有能力，而是依赖于用于此类服务的其他物理接口。这种配置的一个示例是IP隧道接口。
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.
逻辑接口的概述如图1所示。逻辑接口允许异构连接，同时使底层介质中的更改对IP堆栈透明。因此，同步和顺序的网络连接过程是可能的，从而实现技术间和流移动场景。
+----------------------------+
| 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 |
| | | | |
+------+------+ +------+
+----------------------------+
| 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
图1：逻辑接口的一般概述
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
从IP堆栈和应用程序的角度来看，逻辑接口只是另一个接口。事实上，逻辑接口仅在启用时对IP和上层可见。主机看不到逻辑接口和物理接口之间的任何操作差异。与物理接口一样，逻辑接口表示为IP地址配置所针对的软件对象
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.
1. 逻辑接口与它正在抽象的主机上的一组物理接口（子接口）有关系。这些子接口可以随时与逻辑接口连接或分离。附加到逻辑接口的子接口对IP和上层不可见。
2. The logical interface may be attached to multiple access technologies.
2. 逻辑接口可以连接到多址技术。
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.
3. 逻辑接口的发送/接收功能映射到子接口公开的发送/接收服务。此映射是动态的，任何更改对IP堆栈的上层都不可见。
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.
4. 逻辑接口维护其每个子接口的IP流信息。为此，维护了一个概念数据结构。主机可以基于跟踪活动流的每个子接口来填充此信息。
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.
IP层应配置可通过逻辑接口访问的默认路由器。默认路由器可以是逻辑接口的内部，也就是说，它是一个逻辑路由器，反过来决定使用哪个物理接口来传输数据包。
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.
每个逻辑接口都维护一个子接口列表，这些子接口是该逻辑接口构造的一部分。这是一个概念数据结构，称为LIF表。图2显示了一个示例LIF表，其中逻辑接口LIF-1有三个子接口ETH-0、WLAN-0和LTE-0，逻辑接口LIF-2有两个子接口ETH-1和WLAN-1。对于每个LIF条目，该表应存储与该子接口相关联的链路状态和策略（例如，活动或不活动）。在主机上配置路由策略的方法超出了本文档的范围。
+=======================+========================+==================+
| 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 |
+=======================+========================+==================+
+=======================+========================+==================+
| 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
图2：逻辑接口表
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.
逻辑接口还维护与给定子接口关联的流列表，该概念数据结构称为流表。图3显示了一个示例流表，其中流FID-1、FID-2、FID-3、FID-4和FID-5分别与子接口ETH-0、WLAN-0、LTE-0、ETH-1和WLAN-1关联。
+=======================+========================+
| Flow | Sub_Interface |
+=======================+========================+
| FID-1 | ETH-0 |
+=======================+========================+
| FID-2 | WLAN-0 |
+=======================+========================+
| FID-3 | LTE-0 |
+=======================+========================+
| FID-4 | ETH-1 |
+=======================+========================+
| FID-5 | WLAN-1 |
+=======================+========================+
+=======================+========================+
| 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
图3：流程表
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.
流表允许逻辑接口通过特定子接口正确路由每个IP流。逻辑接口可以识别到达其子接口的流，并将它们与这些子接口相关联。这种方法类似于由IP路由器执行的反射QoS。对于本地生成的流量（例如，单播流），逻辑接口应根据流路由策略执行接口选择。如果在与本地存储的子接口不同的子接口上突然从网络接收到现有流的流量，逻辑接口应将该事件解释为来自网络的显式流移动触发器，并应更新流表中的相应条目。类似地，来自子接口的本地生成事件或本地策略规则的配置更新会导致表更新，从而触发流移动。
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.
本节说明如何使用移动节点上的逻辑接口支持来启用某些代理移动IPv6协议功能。
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.
图4显示了一个移动节点，该节点具有连接到代理移动IPv6域的多个接口。在这种情况下，移动节点被配置为在其连接的物理接口上使用逻辑接口。
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 |
+-----------------+
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
图4：多归宿支持
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.
代理移动IPv6协议使具有多个网络接口的移动节点能够在接入技术之间移动，但仍然在其连接的接口上保留相同的地址配置。图5显示了在接入网络之间执行技术间切换的移动节点。该协议使移动节点能够在切换期间实现地址连续性。如果将主机配置为在其连接的物理接口上使用逻辑接口，则以下是相关注意事项。
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 |
+-----------------+
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
图5：技术间切换支持
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.
o 当移动节点在if_1和if_2之间执行切换时，移动节点的应用程序将看不到更改。
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.
o 网元之间的协议信令将确保本地移动锚将广告前缀集的转发从MAG1切换到MAG2。
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.
为了支持IP流移动性，需要支持垂直切换场景，例如从一个接口向另一个接口传输前缀的子集（因此与之相关联的流）。移动节点可以通过使用逻辑接口支持来支持此场景。该场景类似于第6.2节中定义的技术间切换场景；在接口之间只移动前缀的子集。
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.
此外，当LMA决定将特定流从其默认路径移动到不同路径时，IP流移动性通常启动。LMA可以在流被启动时（例如，基于应用策略简档）和/或在流的生存期内，在接收到基于网络或基于移动的触发器时，确定用于转发特定流的最佳MAG。然而，LMA如何制定此类流量政策的具体细节不在本文件范围内。
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.
本规范解释了IP主机上逻辑接口的操作细节。主机上的逻辑接口实现对网络不可见，不需要任何特殊的安全注意事项。
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.
不同的第2层接口及其连接的接入网络具有不同的安全属性。例如，由最终用户操作的无线LAN网络的第2层网络安全由家庭用户控制，而LTE运营商控制LTE接入网络的第2层安全。使用合法手段或通过其他手段的外部实体从LTE运营商获得安全密钥，但在由家庭用户操作的无线LAN网络的情况下，可能不可能获得安全密钥。因此，在某些情况下，将具有此类不同安全属性的接口分组到一个逻辑接口中可能会产生负面后果。这种差异虽然很微妙，但完全被逻辑接口所隐藏，上层不知道。
[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>.
[RFC5213]Gundavelli，S.，Ed.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，DOI 10.17487/RFC5213，2008年8月<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>.
[RFC5844]Wakikawa，R.和S.Gundavelli，“代理移动IPv6的IPv4支持”，RFC 5844，DOI 10.17487/RFC5844，2010年5月<http://www.rfc-editor.org/info/rfc5844>.
[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>.
[RFC2863]McCloghrie，K.和F.Kastenholz，“接口组MIB”，RFC 2863，DOI 10.17487/RFC2863，2000年6月<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>.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 4301，DOI 10.17487/RFC4301，2005年12月<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>.
[RFC5072]Varada，S.，Ed.，Haskins，D.，和E.Allen，“PPP上的IP版本6”，RFC 5072，DOI 10.17487/RFC5072，2007年9月<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>.
[RFC6275]Perkins，C.，Ed.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 6275，DOI 10.17487/RFC6275，2011年7月<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>.
[RFC7223]Bjorklund，M.，“用于接口管理的YANG数据模型”，RFC 7223，DOI 10.17487/RFC7223，2014年5月<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>.
[RFC7864]Bernardos，CJ.，Ed.，“支持流移动的代理移动IPv6扩展”，RFC 7864，DOI 10.17487/RFC7864，2016年5月<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.
[TS23401]第三代合作伙伴项目，“技术规范组服务和系统方面；通用分组无线服务（GPRS）增强，用于演进通用地面无线接入网（E-UTRAN）接入”，TS 23.401，V13.6.012016年3月。
[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.
[TS23402]第三代合作伙伴项目，“技术规范组服务和系统方面；非3GPP接入的架构增强”，TS 23.402，V13.5.0，2016年3月。
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.
作者希望感谢NETLMM和NETEXT工作组对该主题的所有讨论。作者还要感谢Joo Sang Youn、Pierrick Seite、Rajeev Koodli、Basavaraj Patil、Peter McCann、Julien Laganier、Maximilian Riegel、Georgios Karagian、Stephen Farrell和Benoit Claise对本文件的投入。
Contributors
贡献者
This document reflects contributions from the following individuals (listed in alphabetical order):
本文件反映了以下个人的贡献（按字母顺序排列）：
Carlos Jesus Bernardos Cano Email: cjbc@it.uc3m.es
Carlos Jesus Bernardos Cano电子邮件：cjbc@it.uc3m.es
Antonio De la Oliva Email: aoliva@it.uc3m.es
Antonio De la Oliva电子邮件：aoliva@it.uc3m.es
Yong-Geun Hong Email: yonggeun.hong@gmail.com
洪永根电邮：永根。hong@gmail.com
Kent Leung Email: kleung@cisco.com
梁建邦电邮：kleung@cisco.com
Tran Minh Trung Email: trungtm2909@gmail.com
Tran Minh Trung电子邮件：trungtm2909@gmail.com
Hidetoshi Yokota Email: yokota@kddilabs.jp
横田英寿电子邮件：yokota@kddilabs.jp
Juan Carlos Zuniga Email: JuanCarlos.Zuniga@InterDigital.com
胡安·卡洛斯·祖尼加电子邮件：胡安·卡洛斯·祖尼加。Zuniga@InterDigital.com
Authors' Addresses
作者地址
Telemaco Melia (editor) Kudelski Security Geneva Switzerland
Telemaco Melia（编辑）Kudelski安全瑞士日内瓦
Email: telemaco.melia@gmail.com
Email: telemaco.melia@gmail.com
Sri Gundavelli (editor) Cisco 170 West Tasman Drive San Jose, CA 95134 United States
Sri Gundavelli（编辑）思科170西塔斯曼大道圣何塞，加利福尼亚州95134
Email: sgundave@cisco.com
Email: sgundave@cisco.com