[要約] RFC 7847は、IPホストが複数のアクセスをサポートするための論理インターフェースのサポートに関するものです。このRFCの目的は、複数のネットワークインターフェースを持つIPホストの効率的な動作をサポートするための標準化を提供することです。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、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
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プロトコルの主要な目標の1つは、モバイルノードがさまざまなアクセステクノロジーに基づいてアクセスネットワーク全体でハンドオーバーを実行できるようにすることです。このプロトコルは、モバイルノードが異なるアクセスネットワークに同時に接続し、フローベースのアクセス選択を実行できるようにすることも目的として設計されました[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:
このドキュメントで使用されているすべてのモビリティ関連の用語は、Proxy Mobile 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の2つの物理インターフェイスを抽象化することで、論理インターフェイスが作成されている場合があります。これらの物理インターフェース、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 Evolved Packet System [TS23401]の状況です。ユーザー機器（UE）は、3つの異なるアクセステクノロジー（2G GSM / EDGE無線アクセスネットワーク（GERAN）、3Gユニバーサル地上無線アクセスネットワーク）間でアクセスハンドオーバーを実行できます。 （UTRAN）、および4G Evolved 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.
リンク層モビリティサポートは、同じリンク層テクノロジが使用され、その層でモビリティを完全に処理できる場合に適用されます。 1つの例は、共通のIPレイヤー構成（DHCPサーバー、デフォルトルーターなど）を使用して、同じサブネットに複数の802.11アクセスポイントが配置されている場合です。この場合、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.
論理インターフェースは、順次接続に加えて、同時接続をサポートする場合があります。同時アタッチメントを利用するには、ノードとネットワークで追加のサポートが必要です。たとえば、ネットワークから特定のインターフェースをアドレス指定できるようにするには、特別なメカニズムが必要です（フローモビリティなど）。特に、ネットワーク（つまり、モバイルアクセスゲートウェイ（MAG）とローカルモビリティアンカー（LMA））が現在指定されているIPインターフェイスの拡張を使用する代わりに、論理インターフェイスを処理できるようにするには、PMIPv6の拡張が必要です。 RFC5213。RFC5213では、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は、異機種ワイヤレスアクセス用のEvolved Packet System（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.
前のセクションで述べたように、論理インターフェース構造は、ネットワークベースのモビリティのコンテキストで各テクノロジーの詳細をIPレイヤーから隠すことができます（たとえば、PMIPv6に基づくマルチアクセステクノロジーネットワーク）。 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 implementations, the wireless modem is presented to the IP layer as a virtual Ethernet interface.
一部のUE実装では、無線接続のセットアップは、IP層と、IP制御プロトコル（IPCP）およびIPv6制御プロトコル（IPv6CP）[RFC5072]で構成される無線モデムとの間のPPPインターフェイスの作成に基づいています。この場合、PPPインターフェイスにはレイヤー2（L2）アドレスが割り当てられていません。他のいくつかの実装では、ワイヤレスモデムは仮想イーサネットインターフェイスとして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 |
| | | | |
+------+------+ +------+
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 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:
IPスタックとアプリケーションの観点からは、論理インターフェイスは単なる別のインターフェイスです。実際、有効になっている場合、論理インターフェイスはIPおよび上位層にのみ表示されます。ホストは、論理インターフェイスと物理インターフェイスの動作上の違いを認識しません。物理インターフェイスと同様に、論理インターフェイスは、IPアドレス構成がバインドされているソフトウェアオブジェクトとして表されます。ただし、論理インターフェイスには、テクノロジー間のハンドオーバーとフローモビリティ機能を有効にするために不可欠ないくつかの特別なプロパティがあります。これらのプロパティは次のとおりです。
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-1にETH-0、WLAN-0、LTE-0の3つのサブインターフェイスがあり、論理インターフェイスLIF-2にETH-1とWLAN-の2つのサブインターフェイスがあるLIFテーブルの例を示します。 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 |
+=======================+========================+==================+
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 |
+=======================+========================+
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 |
+-----------------+
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 |
+-----------------+
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フローモビリティをサポートするには、プレフィックスのサブセット（したがって、フローに関連付けられているフロー）を1つのインターフェイスから別のインターフェイスに転送するなど、垂直ハンドオフシナリオをサポートする必要があります。モバイルノードは、論理インターフェイスサポートを使用してこのシナリオをサポートできます。このシナリオは、セクション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.
さらに、一般的にIPフローモビリティは、LMAが特定のフローをデフォルトパスから別のフローに移動することを決定したときに開始されます。 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ネットワークの場合、セキュリティキーを取得できない場合があります。したがって、このようなさまざまなセキュリティプロパティを持つインターフェイスを1つの論理インターフェイスにグループ化すると、場合によっては悪影響が生じる可能性があります。このような違いは、わずかではありますが、論理インターフェースによって完全に隠されており、上位層には認識されていません。
[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.、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>.
[RFC5844]脇川R.およびS.ガンダベリ、「プロキシモバイル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、「The Interfaces Group 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.、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>.
[RFC6275] Perkins、C.、Ed。、Johnson、D。、およびJ. Arkko、「Mobility Support in 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。、「A YANG Data Model for Interface Management」、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、編、「フローモビリティをサポートするプロキシモバイル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] 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。
[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]第3世代パートナーシッププロジェクト、「技術仕様グループサービスとシステムの側面、非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
カルロスジーザスベルナルドスカノメール：cjbc@it.uc3m.es
Antonio De la Oliva Email: aoliva@it.uc3m.es
アントニオデラオリーバメール：aoliva@it.uc3m.es
Yong-Geun Hong Email: yonggeun.hong@gmail.com
Yong-GE UN hongメール：UN。红@ Gmail.comを使用してください
Kent Leung Email: kleung@cisco.com
Kent Leungメール：kleung@cisco.com
Tran Minh Trung Email: trungtm2909@gmail.com
Tran Minh Trungメール：trungtm2909@gmail.com
Hidetoshi Yokota Email: yokota@kddilabs.jp
ひでとし よこた えまいｌ： よこた＠ｋっぢぁｂｓ。ｊｐ
Juan Carlos Zuniga Email: JuanCarlos.Zuniga@InterDigital.com
Juan Carlos Zunigaメール：JuanCarlos.Zuniga@InterDigital.com
Authors' Addresses
著者のアドレス
Telemaco Melia (editor) Kudelski Security Geneva Switzerland
Telemaco Melia（編集者）Kudelski Securityジュネーブスイス
Email: telemaco.melia@gmail.com
Sri Gundavelli (editor) Cisco 170 West Tasman Drive San Jose, CA 95134 United States
Sri Gundavelli（編集者）Cisco 170 West Tasman Drive San Jose、CA 95134アメリカ合衆国
Email: sgundave@cisco.com