Internet Engineering Task Force (IETF) M. Blanchet
Request for Comments: 6418 Viagenie
Category: Informational P. Seite
ISSN: 2070-1721 France Telecom - Orange
November 2011
Multiple Interfaces and Provisioning Domains Problem Statement
Abstract
抽象
This document describes issues encountered by a node attached to multiple provisioning domains. This node receives configuration information from each of its provisioning domains, where some configuration objects are global to the node and others are local to the interface. Issues such as selecting the wrong interface to send traffic happen when conflicting node-scoped configuration objects are received and inappropriately used. Moreover, other issues are the result of simultaneous attachment to multiple networks, such as domain selection or addressing and naming space overlaps, regardless of the provisioning mechanism. While multiple provisioning domains are typically seen on nodes with multiple interfaces, this document also discusses situations involving single-interface nodes.
この文書では、複数のプロビジョニングドメインに接続されたノードで発生した問題について説明します。このノードは、いくつかの構成オブジェクトがノードに対してグローバルであり、他のものはインターフェイスにローカルであるそのプロビジョニングドメインの各々から設定情報を受信します。こうした矛盾ノード・スコープの構成オブジェクトを受信し、不適切に使用されている場合に発生トラフィックを送信するために間違ったインターフェースを選択するなどの問題。また、他の問題にかかわらず、プロビジョニング機構のようなドメイン選択又はアドレッシング及び命名空間の重なりのような複数のネットワークへの同時取り付けの結果です。複数のプロビジョニングドメインは、典型的には、複数のインタフェースを有するノードで見られるが、この文書はまた、単一のインターフェースノードを含む状況について論じています。
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc6418.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6418で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Scope and Existing Work .........................................4
3.1. Interactions Below IP ......................................4
3.2. MIF Node Characterization ..................................5
3.3. Host Requirements ..........................................5
3.4. Mobility and Other IP Protocols ............................6
3.5. Address Selection ..........................................6
3.6. Finding and Sharing IP Addresses with Peers ................7
3.7. Provisioning Domain Selection ..............................7
3.8. Session Management .........................................8
3.9. Sockets API ................................................9
4. MIF Issues ......................................................9
4.1. DNS Resolution Issues ......................................9
4.2. Node Routing ..............................................12
4.3. Conflicting Policies ......................................13
4.4. Session Management ........................................14
4.5. Single Interface on Multiple Provisioning Domains .........14
5. Underlying Problems and Causes .................................15
6. Security Considerations ........................................17
7. Contributors ...................................................18
8. Acknowledgements ...............................................18
9. Informative References .........................................18
A multihomed node may have multiple provisioning domains (via physical and/or virtual interfaces). For example, a node may be simultaneously connected to a wired Ethernet LAN, an 802.11 LAN, a 3G cell network, one or multiple VPN connections, or one or multiple tunnels (automatic or manual). Current laptops and smartphones typically have multiple access network interfaces and, thus, are often connected to different provisioning domains.
マルチホーム・ノードが（物理的および/または仮想インタフェースを介して）複数のプロビジョニングドメインを有していてもよいです。例えば、ノードが同時に有線イーサネットLAN、802.11 LAN、3Gセルネットワーク、一つまたは複数のVPN接続、または1つまたは複数のトンネル（自動または手動）に接続されてもよいです。現在ノートパソコンやスマートフォンは、典型的には、複数のアクセスネットワークインタフェースを有し、したがって、しばしば異なるプロビジョニングドメインに接続されています。
A multihomed node receives configuration information from each of its attached networks, through various mechanisms such as DHCPv4 [RFC2131], DHCPv6 [RFC3315], PPP [RFC1661], and IPv6 Router Advertisements [RFC4861]. Some received configuration objects are specific to an interface, such as the IP address and the link prefix. Others are typically considered by implementations as being global to the node, such as the routing information (e.g., default gateway), DNS server IP addresses, and address selection policies, herein referred to as "node-scoped".
マルチホーム・ノードは、DHCPv4の[RFC2131]、DHCPv6の[RFC3315]、PPP [RFC1661]、およびIPv6ルータ広告[RFC4861]などの様々なメカニズムを介して、その接続されたネットワークのそれぞれから構成情報を受信します。いくつかの受信設定オブジェクトには、IPアドレスやリンクの接頭辞として、インタフェースに固有のものです。他のものは、典型的には、DNSサーバのIPアドレス、そのようなルーティング情報（例えば、デフォルトゲートウェイ）として、ノードに対してグローバルであると実装によって考慮され、本明細書では「ノードスコープ」と呼ばれるアドレス選択ポリシーれます。
When the received node-scoped configuration objects have different values from each provisioning domain, such as different DNS server IP addresses, different default gateways, or different address selection policies, the node has to decide which one to use or how it will merge them.
受信したノード・スコープの構成オブジェクトは、別のDNSサーバーのIPアドレス、異なるデフォルトゲートウェイ、または異なるアドレス選択ポリシーなど、各プロビジョニングドメインとは異なる値を持っている場合は、ノードが使用する1またはそれはそれらをマージする方法を決定する必要があります。
Other issues are the result of simultaneous attachment to multiple networks, such as addressing and naming space overlaps, regardless of the provisioning mechanism.
他の問題は、このような関係なく、プロビジョニング機構の、アドレッシング及び空間重複を命名するなど、複数のネットワークへの同時結合の結果です。
The following sections define the multiple interfaces (MIF) node and the scope of this work, describe related work, list issues, and then summarize the underlying problems.
以下のセクションでは、複数のインタフェース（MIF）ノードと、この作業の範囲を定義し、関連作業、リストの問題について説明し、その後、根本的な問題を要約します。
A companion document, [RFC6419], discusses some current practices of various implementations dealing with MIF.
仲間ドキュメントは、[RFC6419]は、MIFを扱う様々な実装のいくつかの現在の慣行について説明します。
Administrative domain
管理ドメイン
A group of hosts, routers, and networks operated and managed by a single organization [RFC1136].
ホスト、ルータ、およびネットワークのグループが動作し、単一の組織[RFC1136]によって管理します。
Provisioning domain
プロビジョニングドメイン
A set of consistent configuration information (e.g., default router, network prefixes, DNS) and the corresponding interface. One administrative domain may have multiple provisioning domains. Successful attachment to the provisioning domain implies that the terminal attaches to the corresponding interface with appropriate configuration information.
一貫性のあるコンフィギュレーション情報（例えば、デフォルトルータ、ネットワークプレフィックス、DNS）及び対応するインタフェースのセット。 1つの管理ドメインには、複数のプロビジョニングドメインを有することができます。プロビジョニングドメインに成功したアタッチメントは、端末が適切な設定情報を対応するインタフェースに付着することを意味します。
Reference to IP version
IPバージョンへの参照
When a protocol keyword such as IP, PPP, or DHCP is used in this document without any reference to a specific IP version, then it implies both IPv4 and IPv6. A specific IP version keyword such as DHCPv4 or DHCPv6 is meant to be specific to that IP version.
このようなIP、PPP、またはDHCPのようなプロトコルキーワードが特定のIPバージョンへの参照せずに、この文書で使用される場合、それは、IPv4とIPv6の両方を意味しています。このようのDHCPv4またはDHCPv6のような特定のIPバージョンキーワードは、そのIPバージョンに固有であることを意味します。
This section describes existing related work and defines the scope of the problem.
このセクションでは、既存の関連研究について説明し、問題の範囲を定義します。
Some types of interfaces have link-layer characteristics that may be used in determining how multiple provisioning domain issues will be dealt with. For instance, link layers may have authentication and encryption characteristics that could be used as criteria for interface selection. However, network discovery and selection on lower layers as defined by [RFC5113] is out of scope of this document. Moreover, interoperability with lower-layer mechanisms such as services defined in IEEE 802.21, which aims at facilitating handover between heterogeneous networks [MIH], is also out of scope.
インタフェースの種類によっては、複数のプロビジョニングドメインの問題が扱われる方法を決定する際に使用することができるリンク層の特性を有しています。例えば、リンク層は、インタフェースを選択するための基準として使用することができる認証および暗号化の特性を有していてもよいです。しかしながら、[RFC5113]で定義されるような下位層のネットワークの発見および選択は、この文書の範囲外です。また、このような異種ネットワーク【MIH]との間のハンドオーバを容易にすることを目的とIEEE 802.21で定義されたサービスとして下層機構との相互運用性は、範囲の外でもあります。
Some mechanisms (e.g., based on a virtual IP interface) allow sharing a single IP address over multiple interfaces to networks with disparate access technologies. From the IP-stack view on the node, there is only a single interface and single IP address. Therefore, this situation is out of scope of this problem statement. Furthermore, link aggregation done under IP where a single interface is shown to the IP stack is also out of scope.
（仮想IPインターフェイスに基づいて、例えば、）いくつかのメカニズムは、異なるアクセス技術を用いてネットワークへの複数のインターフェイス上の単一のIPアドレスを共有することを可能にします。ノード上のIPスタックビューからは、単一のインタフェースのみと単一のIPアドレスがあります。したがって、このような状況では、この問題文の範囲外です。さらに、単一のインタフェースがIPスタックに示されているIPの下で行わリンクアグリゲーションは、範囲外でもあります。
A MIF node has the following characteristics:
MIFのノードは、次の特性を有しています。
o A MIF node is an [RFC1122] IPv4- and/or [RFC4294] IPv6-compliant node.
O MIFノードは[RFC1122] IPv4-および/または[RFC4294]のIPv6対応のノードです。
o A MIF node is configured with more than one IP address (excluding loopback and link-local).
O MIFノードが（ループバック及びリンクローカル除く）複数のIPアドレスが設定されています。
o A MIF node can attach to more than one provisioning domain, as presented to the IP stack.
IPスタックに提示されるO MIFノードは、複数のプロビジョニング・ドメインに接続することができます。
o The interfaces may be virtual or physical.
Oインタフェースは、仮想的または物理的であってもよいです。
o Configuration objects come from one or more administrative domains.
O構成オブジェクトは、1つ以上の管理ドメインから来ます。
o The IP addresses may be from the same or different address families, such as IPv4 and IPv6.
O IPアドレスは、IPv4とIPv6と同じまたは異なるアドレスファミリーからのものであってもよいです。
o Communications using these IP addresses may happen simultaneously and independently.
O通信は同時に独立に起こることがあり、これらのIPアドレスを使用して。
o Some communications using these IP addresses are possible on all the provisioning domains, while some are only possible on a smaller set of the provisioning domains.
これらのIPアドレスを使用していくつかの通信O一部は、プロビジョニングドメインの小さなセットでのみ可能であるが、すべてのプロビジョニングドメインで可能です。
o While the MIF node may forward packets between its interfaces, the forwarding of packets is not taken into account in this definition and is out of scope for this document.
MIFのノードは、そのインターフェイス間でパケットを転送することができるが、O、パケットの転送は、この定義に考慮されておらず、この文書の範囲外です。
"Requirements for Internet Hosts -- Communication Layers" [RFC1122] describes the multihomed node as if it has multiple IP addresses, which may be associated with one or more physical interfaces connected to the same or different networks.
「インターネットホストのための要件 - 通信層」とは、同一または異なるネットワークに接続された1つの以上の物理インターフェイスに関連付けることができる複数のIPアドレスを持つかのように[RFC1122]は、マルチホームノードが記載されています。
Section 3.3.1.3 of [RFC1122] states that the node maintains a route cache table where each entry contains the local IP address, the destination IP address, Type(s) of Service (superseded by the Differentiated Services Code Point [RFC2474]), and the next-hop gateway IP address. The route cache entry would have data about the properties of the path, such as the average round-trip delay measured by a transport protocol. Nowadays, implementations are not caching this information.
[RFC1122]のセクション3.3.1.3は、ノードは、各エントリは、ローカルIPアドレス、（差別化サービスコードポイント[RFC2474]に取って代わら）サービスの宛先IPアドレス、タイプ（複数可）を含有するルートキャッシュテーブルを維持することを述べてそして、ネクストホップゲートウェイIPアドレス。ルートキャッシュエントリは、トランスポートプロトコルによって測定された平均ラウンドトリップ遅延として経路の特性に関するデータを有することになります。今日では、実装はこの情報をキャッシュされていません。
[RFC1122] defines two host models:
[RFC1122]は2つのホストモデルを定義しています。
o The "strong" host model defines a multihomed host as a set of logical hosts within the same physical host. In this model, a packet must be sent on an interface that corresponds to the source address of that packet.
O「強い」ホスト・モデルは、同一の物理ホスト内の論理ホストのセットとしてマルチホームホストを定義します。このモデルでは、パケットは、そのパケットの送信元アドレスに対応するインターフェイス上で送信されなければなりません。
o The "weak" host model describes a host that has some embedded gateway functionality. In the weak host model, the host can send and receive packets on any interface.
O「弱い」ホストモデルは、いくつかの埋込みゲートウェイ機能を持つホストが記載されています。弱いホストモデルでは、ホストは、任意のインターフェイス上でパケットを送信および受信することができます。
The multihomed node computes routes for outgoing datagrams differently, depending on the model. Under the strong model, the route is computed based on the source IP address, the destination IP address, and the Differentiated Services Code Point. Under the weak model, the source IP address is not used; only the destination IP address and the Differentiated Services Code Point are used.
マルチホーム・ノードは、モデルに応じて、異なる発信データグラムの経路を計算します。強いモデルでは、ルートは、送信元IPアドレス、宛先IPアドレス、および差別化サービスコードポイントに基づいて計算されます。弱いモデルの下では、送信元IPアドレスが使用されていません。唯一の宛先IPアドレスと差別化サービスコードポイントが使用されています。
The scope of this document is only about nodes implementing [RFC1122] for IPv4 and [RFC4294] for IPv6 without additional features or special-purpose support for transport layers, mobility, multihoming, or identifier-locator split mechanisms. Dealing with multiple interfaces with such mechanisms is related but considered as a separate problem and is under active study elsewhere in the IETF [RFC4960] [RFC5206] [RFC5533] [RFC5648] [RFC6182].
この文書の範囲は、追加の特徴または輸送層、モビリティ、マルチホーミング、または識別子ロケータ分離機構の専用サポートなしでIPv6のIPv4および[RFC4294]のために[RFC1122]を実装するノードについてです。そのような機構を複数のインターフェースを扱うことに関連しているが、別の問題として考えられ、他の場所IETF [RFC4960]、[RFC5206]、[RFC5533]、[RFC5648]、[RFC6182]で活性検討されています。
When an application is using one interface while another interface with better characteristics becomes available, the ongoing application session could be transferred to the newly enabled interface. However, in some cases, the ongoing session shall be kept on the current interface while initiating the new session on the new interface. The problem of interface selection is within the MIF scope and may leverage specific node functions (Section 3.8). However, if transfer of an IP session is required, IP mobility mechanisms, such as [RFC6275], shall be used.
より良好な特性を有する別のインターフェイスが使用可能になっている間、アプリケーションが一つのインタフェースを使用している場合、進行中のアプリケーションセッションは、新たに有効インタフェースに転送することができます。新しいインターフェイスで新しいセッションを開始しながら、しかし、いくつかのケースでは、進行中のセッションでは、現在のインタフェース上に維持されなければなりません。インタフェース選択の問題は、MIFの範囲内であり、特定のノードの機能（セクション3.8）を利用してもよいです。 IPセッションの転送が必要な場合は、このような[RFC6275]としてIPモビリティメカニズムが、使用されなければなりません。
"Default Address Selection for Internet Protocol version 6 (IPv6)" [RFC3484] defines algorithms for source and destination IP address selections. Default address selection as defined in [RFC3484] is mandatory to implement in IPv6 nodes, which also means dual-stack nodes. A node-scoped policy table managed by the IP stack is defined. Mechanisms to update the policy table are defined in [ADDR-SELECT-SOL].
「デフォルトアドレス選択は、インターネットプロトコルバージョン6（IPv6）のために」[RFC3484]は送信元および宛先IPアドレスを選択するためのアルゴリズムを定義します。 [RFC3484]で定義されるように、デフォルトのアドレス選択はまた、デュアルスタックノードを意味し、IPv6ノードに実装することが必須です。 IPスタックにより、管理対象ノード・スコープのポリシーテーブルが定義されています。ポリシーテーブルを更新するメカニズムは[ADDR-SELECT-SOL]で定義されています。
Issues on using default address selection were found in [RFC5220] and [RFC5221] in the context of multiple prefixes on the same link.
デフォルトのアドレス選択を使用しての課題は、同じリンク上の複数のプレフィックスのコンテキスト内で、[RFC5220]と[RFC5221]で発見されました。
Interactive Connectivity Establishment (ICE) [RFC5245] is a technique for NAT traversal for UDP-based (and TCP-based) media streams established by the offer/answer model. The multiplicity of IP addresses, ports, and transport mechanisms in Session Description Protocol (SDP) offers are tested for connectivity by peer-to-peer connectivity checks. The result is candidate IP addresses and ports for establishing a connection with the other peer. However, ICE does not solve issues when incompatible configuration objects are received on different interfaces.
インタラクティブ接続確立（ICE）[RFC5245]は、オファー/アンサーモデルによって確立されたUDPベースのNATトラバーサルのための技術（およびTCPベースの）メディアストリームです。セッション記述プロトコルにおけるIPアドレス、ポート、およびトランスポート機構の多数は（SDP）オファーは、ピア・ツー・ピア接続をチェックして接続するために試験されます。結果は、他のピアとの接続を確立するための候補となるIPアドレスおよびポートです。互換性のない構成オブジェクトが異なるインターフェイス上で受信されたときしかし、ICEは、問題を解決していません。
Some application protocols do referrals of IP addresses, port numbers, and transport for further exchanges. For instance, applications can provide reachability information to themselves or to a third party. The general problem of referrals is related to the multiple-interface problem, since, in this context, referrals must provide consistent information depending on which provisioning domain is used. Referrals are discussed in [REFERRAL-PS] and [SHIM6-APP-REFER].
いくつかのアプリケーションプロトコルは、IPアドレス、ポート番号、および更なる交流のための輸送の紹介を行います。例えば、アプリケーションは、自分自身や第三者への到達可能性情報を提供することができます。この文脈において、照会が使用されるプロビジョニングドメインに応じて一貫した情報を提供しなければならないので、紹介の一般的な問題は、複数のインタフェースの問題に関連しています。照会は、[参照-PS]と[SHIM6-APPは、参照]に記載されています。
In a MIF context, the node may simultaneously handle multiple domains with disparate characteristics, especially when supporting multiple access technologies. Selection is simple if the application is restricted to one specific provisioning domain: the application must start on the default provisioning domain if available; otherwise, the application does not start. However, if the application can be run on several provisioning domains, the selection problem can be difficult.
MIFの文脈において、ノードは、同時に複数のアクセス技術をサポートしている場合は特に、異なる特性を持つ複数のドメインを処理することができます。アプリケーションは、1つの特定のプロビジョニングドメインに制限されている場合の選択は簡単です：アプリケーションが使用可能な場合、デフォルトのプロビジョニングドメインに開始する必要があります。そうでない場合は、アプリケーションが起動しません。アプリケーションが複数のプロビジョニングドメイン上で実行することができる場合は、選択の問題が困難な場合があります。
There is no standard method for selecting a provisioning domain, but some recommendations exist while restricting the scope to the interface selection problem. For example, [TS23.234] proposes a default mechanism for the interface selection. This method uses the following information (non-exhaustive list):
そこプロビジョニングドメインを選択するための標準的な方法ではありませんが、インタフェース選択問題への適用範囲を制限しながら、いくつかの推奨事項が存在します。例えば、[TS23.234]はインタフェース選択のデフォルトのメカニズムが提案されています。この方法は、以下の情報（非網羅的なリスト）を使用しています。
o preferences provided by the user
ユーザによって提供さOの好み
o policies provided by the network operator
ネットワークオペレータが提供するOポリシー
o quality of the radio link o network resource considerations (e.g., available Quality of Service (QoS), IP connectivity check)
無線リンクOネットワークリソースの考慮事項のOの品質（例えば、利用可能なサービス品質（QoS）の、IP接続性チェック）
o the application QoS requirements in order to map applications to the best interface
最高のインターフェイスにアプリケーションをマッピングするために、アプリケーションのQoS要件O
However, [TS23.234] is designed for a specific multiple-interfaces use case. A generic way to handle these characteristics is yet to be defined.
しかし、[TS23.234]特定の複数のインターフェイスのユースケースのために設計されています。これらの特性を処理するための汎用的な方法は、まだ定義されています。
Some implementations, especially in the mobile world, rely on a higher-level session manager, also called a connection manager, to deal with issues brought by simultaneous attachment to multiple provisioning domains. Typically, the session manager may deal with the selection of the interface, and/or the provisioning domain, on behalf of the applications, or tackle complex issues such as how to resolve conflicting policies (Section 4.3). As discussed in Section 3.7, the session manager may encounter difficulties because of multiple and diverse criteria.
いくつかの実装は、特にモバイルの世界では、また、複数のプロビジョニングドメインへの同時接続によってもたらされる問題に対処するために、接続マネージャと呼ばれる、より高いレベルのセッションマネージャに依存しています。一般的に、セッションマネージャは、アプリケーションに代わって、インターフェースの選択、および/またはプロビジョニングドメインを扱う、またはそのような矛盾する政策（4.3節）を解決する方法として、複雑な問題に取り組むことがあります。セクション3.7で議論するように、セッション・マネージャは、複数の理由で多様な基準の問題が発生する可能性があり。
Session managers usually leverage the link-layer interface to gather information (e.g., lower-layer authentication and encryption methods; see Section 3.1) and/or for control purposes. Such a link-layer interface may not provide all required services to make a proper decision (e.g., interface selection). Some OSes or terminals already implement session managers [RFC6419], and vendor-specific platforms sometimes provide a specific sockets API (Section 3.9) that a session manager can use. However, the generic architecture of a session manager and its associated API are not currently standardized, so session manager behavior may differ between OSes and platforms.
（例えば、下層の認証方式と暗号化方式、セクション3.1を参照）、セッション・マネージャは、通常の情報を収集するためにリンク層インターフェースを活用および/または制御のために。そのようなリンク層インターフェースは、適切な決定（例えば、インタフェースの選択）を行うために必要なすべてのサービスを提供しないかもしれません。いくつかのOS又は端末が既にセッションマネージャ[RFC6419]を実装し、ベンダー固有のプラットフォームは、時々、セッションマネージャが使用することができる特定のソケットAPI（セクション3.9）を提供します。しかし、セッションマネージャとその関連APIの一般的なアーキテクチャは、現在、標準化されていないので、セッションマネージャの動作は、OSやプラットフォーム間で異なる場合があります。
Management of multiple interfaces sometimes relies on a virtual interface. For instance, a virtual interface allows support of multihoming, inter-technology handovers, and IP flow mobility in a Proxy Mobile IPv6 network [LOGICAL-IF-SUPPORT]. This virtual interface allows a multiple-interface node sharing a set of IP addresses on multiple physical interfaces and can also add benefits to multi-access scenarios such as Third Generation Partnership Project (3GPP) Multi Access Packet Data Network (PDN) Connectivity [TS23.402]. In most cases, the virtual interface will map several physical network interfaces, and the session manager should control the configuration of each one of these virtual and physical interfaces, as well as the mapping between the virtual and sub-interfaces.
複数のインターフェースの管理は、時として仮想インターフェイスに依存しています。例えば、仮想インタフェースはプロキシモバイルIPv6ネットワーク[論理IF-SUPPORT]でマルチホーミング、技術間ハンドオーバー、及びIPフローモビリティのサポートを可能にします。この仮想インタフェースは、IPのセットを共有する複数のインタフェース・ノードは、複数の物理インタフェース上のアドレスと、そのような第三世代パートナーシッププロジェクト（3GPP）のマルチアクセスパケットデータネットワーク（PDN）接続[TS23などのマルチアクセスシナリオに利益を追加することができる可能にします。 402]。ほとんどの場合、仮想インタフェースは、複数の物理ネットワーク・インターフェースをマッピングし、セッション・マネージャは、これらの仮想および物理インターフェイスのそれぞれの構成、ならびに仮想サブインターフェースとの間のマッピングを制御しなければなりません。
In a situation involving multiple interfaces, active application sessions should survive path failures. Here, the session manager may come into play but only relying on existing mechanisms to manage multipath TCP (MPTCP) [RFC6182] or failover (Mobile IPv6 (MIP6) [RFC6275], Shim6 [RFC5533]). A description of the interaction between these mechanisms and the session manager is out of scope of this document.
複数のインターフェースに関わるような状況では、アクティブなアプリケーションセッションは、パスの障害を乗り切る必要があります。ここでは、セッションマネージャは、遊びに来るかもしれないが、唯一のマルチパスTCP（MPTCP）[RFC6182]またはフェールオーバー（モバイルIPv6（MIP6）[RFC6275]、SHIM6 [RFC5533]）を管理するために、既存のメカニズムに依存します。これらの機構およびセッション・マネージャとの間の相互作用の記述は、この文書の範囲外です。
An Application Programming Interface (API) may expose objects that user applications or session managers use for dealing with multiple interfaces. For example, [RFC3542] defines how an application using the advanced sockets API specifies the interface or the source IP address through a simple bind() operation or with the IPV6_PKTINFO socket option.
アプリケーション・プログラミング・インターフェース（API）は、ユーザ・アプリケーションまたはセッション・マネージャは、複数のインターフェースを扱うために使用するオブジェクトを公開することができます。例えば、[RFC3542]は、高度なソケットAPIを使用するアプリケーションは、単純なバインド（）オペレーションを介して、またはIPV6_PKTINFOソケットオプションとインターフェイスまたは送信元IPアドレスを指定する方法を定義します。
Other APIs have been defined to solve issues similar to MIF. For instance, [RFC5014] defines an API to influence the default address selection mechanism by specifying attributes of the source addresses it prefers. [RFC6316] gives another example, in a multihoming context, by defining a sockets API enabling interactions between applications and the multihoming shim layer for advanced locator management, and access to information about failure detection and path exploration.
その他のAPIは、MIFと同様の問題を解決するために定義されています。例えば、[RFC5014]は、それが好む送信元アドレスの属性を指定することで、デフォルトのアドレス選択メカニズムに影響を与えるためのAPIを定義します。 [RFC6316]は、アプリケーションおよび高度ロケータ管理のためのマルチホーミングシム層、及び障害検出及びパス探索に関する情報へのアクセスとの間の相互作用を可能にするソケットAPIを定義することによって、マルチホーミング文脈において、別の例を示します。
This section describes the various issues when using a MIF node that has already received configuration objects from its various provisioning domains, or when multiple interfaces are used and result in wrong domain selection, addressing, or naming space overlaps. They occur, for example, when:
すでに様々なプロビジョニングドメインから構成オブジェクトを受信したMIFのノードを使用して、または複数のインターフェイスが使用され、間違ったドメイン選択をもたらしている場合、アドレス指定、またはスペースが重複命名する場合、このセクションでは、さまざまな問題を記載しています。彼らが発生し、例えば、とき：
1. one interface is on the Internet and one is on a corporate private network. The latter may be through VPN.
1. 1インタフェースは、インターネット上にあり、一つは、企業のプライベートネットワーク上にあります。後者は、VPNを介してもよいです。
2. one interface is on one access network (i.e., WiFi) and the other one is on another access network (3G) with specific services.
2つのインターフェースは、一つのアクセスネットワーク（すなわち、無線LAN）上にあり、他の一つは、特定のサービスを別のアクセスネットワーク（3G）です。
A MIF node (M1) has an active interface (I1) connected to a network (N1), which has its DNS servers (S1 as primary DNS server) and another active interface (I2) connected to a network (N2), which has its DNS servers (S2 as primary DNS server). S1 serves some private namespace, "private.example.com". The user or the application uses a name "a.private.example.com", which is within the private namespace of S1 and only resolvable by S1. Any of the following situations may occur:
MIFノード（M1）は、DNSサーバを有するネットワーク（N1）に接続されたアクティブインタフェース（I1）を有する（S1プライマリDNSサーバなど）を有するネットワーク（N2）に接続され、別のアクティブインタフェース（I2）そのDNSサーバ（プライマリDNSサーバとしてS2）。 S1は、いくつかのプライベート名前空間、「private.example.com」を提供しています。ユーザーまたはアプリケーションは、S1のプライベート名前空間内およびS1によってのみ解決可能である名称「a.private.example.com」を、使用しています。次のいずれかの状況が発生する可能性があります。
1. The M1 stack, based on its routing table, uses I2 to reach S1 to resolve "a.private.example.com". M1 never reaches S1. The name is not resolved.
1. M1スタックは、そのルーティングテーブルに基づいて、「a.private.example.com」解決するS1に到達するためにI2を使用します。 M1は、S1に達することはありません。名前が解決されません。
2. M1 keeps only one set of DNS server addresses from the received configuration objects. Let us assume that M1 keeps S2's address as the primary DNS server. M1 sends the forward DNS query for a.private.example.com to S2. S2 responds with an error for a nonexistent domain (NXDOMAIN). The name is not resolved. This issue also arises when performing a reverse DNS lookup. In the same situation, the reverse DNS query fails.
2. M1は、受信設定オブジェクトからDNSサーバーのアドレスを1セットのみ保持します。私たちは、M1は、プライマリDNSサーバーとしてS2のアドレスを保持していると仮定しましょう。 M1は、S2へa.private.example.comための前方DNSクエリを送信します。 S2は、存在しないドメイン（NXDOMAIN）のエラーで応答します。名前が解決されません。逆DNSルックアップを実行するときにも、この問題が発生します。同じような状況では、リバースDNSクエリが失敗します。
3. M1 keeps only one set of DNS server addresses from the received configuration objects. Let us assume that M1 keeps S2's address. M1 sends the DNS query for a.private.example.com to S2. S2 queries its upstream DNS and gets an IP address for a.private.example.com. However, the IP address is not the same one that S1 would have given. Therefore, the application tries to connect to the wrong destination node, or to the wrong interface, which may imply security issues or result in lack of service.
3. M1は、受信設定オブジェクトからDNSサーバーのアドレスを1セットのみ保持します。私たちは、M1は、S2のアドレスを保持していると仮定しましょう。 M1は、S2へa.private.example.comのためのDNSクエリを送信します。 S2は、その上流のDNSを照会し、a.private.example.comのためのIPアドレスを取得します。しかし、IPアドレスは、S1が与えられているのと同じものではありません。したがって、アプリケーションが間違った宛先ノードへ、またはセキュリティ上の問題を暗示やサービスの欠如をもたらす可能性が間違ったインターフェイスに接続しようとします。
4. S1 or S2 has been used to resolve "a.private.example.com" to an [RFC1918] address. Both N1 and N2 are [RFC1918]-addressed networks. If addresses overlap, traffic may be sent using the wrong interface. This issue is not related to receiving multiple configuration objects, but to an address overlap between interfaces or attaching networks.
4. S1又はS2は、[RFC1918]のアドレスに「a.private.example.com」を解決するために使用されてきました。 N1とN2の両方が[RFC1918] -addressedネットワークです。アドレスが重複した場合は、トラフィックが間違ったインターフェースを使用して送信することができます。この問題は、複数のコンフィギュレーション・オブジェクトを受信することに関連しないが、インターフェイスまたは取り付けるネットワーク間のアドレス重複します。
5. M1 has resolved a Fully Qualified Domain Name (FQDN) to a locally valid IP address when connected to N1. If the node loses connection to N1, the node may try to connect, via N2, to the same IP address as earlier, but as the address was only locally valid, connection setup fails. Similarly, M1 may have received NXDOMAIN for an FQDN when connected to N1. After detachment from N1, the node should not assume the FQDN continues to be nonexistent on N2.
N1に接続したとき5. M1は、ローカルで有効なIPアドレスに完全修飾ドメイン名（FQDN）を解決しました。ノードはN1への接続を失った場合、ノードは以前と同じIPアドレスに、N2を経由して、接続してみますが、アドレスがローカルでのみ有効であったように、接続設定は失敗します。 N1に接続されている場合同様、M1は、FQDNのためにNXDOMAINを受けていてもよいです。 N1から剥離した後、ノードは、FQDNがN2に存在しないであり続けると仮定してはなりません。
6. M1 requests a AAAA record from a DNS server on a network that uses protocol translators and DNS64 [RFC6147]. If M1 receives a synthesized AAAA record, it is guaranteed to be valid only on the network from which it was learned. If M1 uses synthesized AAAA on any other network interface, traffic may be lost, dropped, or forwarded to the wrong network.
前記M1は、プロトコルトランスレータとDNS64 [RFC6147]を使用してネットワーク上のDNSサーバからAAAAレコードを要求します。 M1は、合成されたAAAAレコードを受信した場合、唯一それが学習されたネットワーク上で有効であることが保証されます。 M1は、他のネットワーク・インターフェース上に合成AAAAを使用している場合、トラフィックは、失われたドロップ、または間違ったネットワークに転送することができます。
Some networks require the user to authenticate on a captive web portal before providing Internet connectivity. If this redirection is achieved by modifying the DNS reply, specific issues may occur. Consider a MIF node (M1) with an active interface (I1) connected to a network (N1), which has its DNS server (S1), and another active interface (I2) connected to a network (N2), which has its DNS server (S2). Until the user has not authenticated, S1 is configured to respond to any A or AAAA record query with the IP address of a captive portal, so as to redirect web browsers to an access control portal web page. This captive portal can be reached only via I1. When the user has authenticated to the captive portal, M1 can resolve an FQDN when connected to N1. However, if the address is only locally valid on N1, any of the issues described above may occur. When the user has not authenticated, any of the following situations may occur:
ネットワークによっては、インターネット接続を提供する前に、キャプティブWebポータルでの認証にユーザーが必要となります。このリダイレクトは、DNS応答を修正することにより達成されている場合は、特定の問題が発生することがあります。そのDNSサーバ（S1）を有するネットワーク（N1）に接続されたアクティブインタフェース（I1）、そのDNSを有するネットワーク（N2）に接続された他のアクティブインタフェース（I2）とMIFのノード（M1）を考えますサーバー（S2）。ユーザーが認証されていないまで、S1は、アクセス制御ポータルWebページにWebブラウザをリダイレクトするように、キャプティブポータルのIPアドレスを持つ任意のAまたはAAAAレコードクエリに応答するように構成されています。このキャプティブポータルはI1を介して到達することができます。ユーザーは、キャプティブポータルに認証されている場合はN1に接続されたときに、M1は、FQDNを解決することができます。アドレスはローカルでのみ有効N1オンになっている場合は、上記のいずれかの問題が発生することがあります。ユーザーが認証されていない場合は、次のいずれかの状況が発生する可能性があります。
1. M1 keeps only one set of DNS server addresses from the received configuration objects and kept S2 address. M1 sends the forward DNS query for a.example.com to S2. S2 responds with the correct answer, R1. M1 attempts to contact R1 by way of I1. The connection fails. Or, the connection succeeds, bypassing the security policy on N1, possibly exposing the owner of M1 to prosecution.
1. M1は、受信された構成オブジェクトからDNSサーバアドレスのセットを1つだけ保持し、S2のアドレスを保持しました。 M1は、S2へa.example.comための前方DNSクエリを送信します。 S2は正解、R1で応答します。 M1はI1を介してR1に連絡しようとします。接続は失敗します。または、接続はおそらく起訴にM1の所有者をさらす、N1上のセキュリティポリシーをバイパスし、成功しました。
2. M1 keeps only one set of DNS server addresses from the received configuration objects and kept S1 address. M1 sends the DNS query for a.example.com to S1. S1 provides the address of its captive portal. M1 attempts to contact this IP address using I1. The application fails to connect, resulting in lack of service. Or, the application succeeds in connecting but connects to the captive portal rather than the intended destination, resulting in lack of service (i.e., an IP connectivity check issue, as described in Section 4.4).
2. M1は、受信設定オブジェクトからDNSサーバーのアドレスを1セットのみ保持し、S1アドレスを保ちました。 M1は、S1にa.example.comのためのDNSクエリを送信します。 S1は、そのキャプティブポータルのアドレスを提供します。 M1はI1を使用して、このIPアドレスに連絡しようとします。アプリケーションは、サービスの欠如、その結果、接続に失敗します。あるいは、アプリケーションは、接続に成功したが、サービスの欠如をもたらす、キャプティブポータルではなく意図された宛先に接続する（すなわち、IP接続性チェックの問題、セクション4.4で説明したように）。
Consider a MIF node (M1) with an active interface (I1) connected to a network (N1) and another active interface (I2) connected to a network (N2). The user or the application is trying to reach an IP address (IP1). Any of the following situations may occur:
ネットワーク（N1）とネットワーク（N2）に接続された他のアクティブインタフェース（I2）に接続されたアクティブインタフェース（I1）を有するMIFノード（M1）を考えます。ユーザーまたはアプリケーションがIPアドレス（IP1）を到達しようとしています。次のいずれかの状況が発生する可能性があります。
1. For IP1, M1 has one default route (R1) via network (N1). To reach IP1, the M1 stack uses R1 and sends through I1. If IP1 is only reachable by N2, IP1 is never reached or is not the right target.
IP1、M1について1.ネットワーク（N1）を介してデフォルトルート（R1）を有します。 IP1に到達するには、M1スタックはR1を使用し、I1を通じて送信します。 IP1はN2によってのみ到達可能である場合には、IP1に達することはありませんか右対象ではありません。
2. For the IP1 address family, M1 has one default route (R1, R2) per network (N1, N2). IP1 is reachable by both networks, but the N2 path has better characteristics, such as better round-trip time, least cost, better bandwidth, etc. These preferences could be defined by the user, provisioned by the network operator, or otherwise appropriately configured. The M1 stack uses R1 and tries to send through I1. IP1 is reached, but the service would be better via I2.
IP1アドレスファミリの2、M1は、ネットワーク（N1、N2）につき1つのデフォルトルート（R1、R2）を持っています。 IP1は、両方のネットワークによって到達可能であるが、N2のパスは、より良好な往復時間として良好な特性を有する、等最小コスト、より良好な帯域幅、これらのプリファレンスは、ユーザによって定義されたネットワークオペレータによってプロビジョニング、または他の方法で適切に設定することができます。 M1スタックは、R1を使用し、I1を通じて送信しようとします。 IP1に達しているが、サービスがI2を経由して良いだろう。
3. For the IP1 address family, M1 has a default route (R1), a specific X.0.0.0/8 route R1B (for example, but not restricted to an [RFC1918] prefix) to N1, and a default route (R2) to N2. IP1 is reachable by N2 only, but the prefix (X.0.0.0/8) is used in both networks. Because of the most specific route R1B, the M1 stack sends packets through I2, and those packets never reach the target.
IP1アドレスファミリの3は、M1は、（N1にデフォルトルート（R1）、特定X.0.0.0 / 8経路（例えば、しかし[RFC1918]プレフィックスに限定されない）R1Bを有しており、デフォルトルートN2にR2）。 IP1は、N2によって到達可能であるが、接頭辞（X.0.0.0 / 8）は、両方のネットワークで使用されています。そのため、ほとんどの特定のルートR1Bの、M1スタックがI2を介してパケットを送信し、それらのパケットは、目標に到達することはありません。
A MIF node may have multiple routes to a destination. However, by default, it does not have any hint concerning which interface would be the best to use for that destination. The first-hop selection may leverage on local routing policy, allowing some actors (e.g., network operator or service provider) to influence the routing table, i.e., make a decision regarding which interface to use. For instance, a user on such a multihomed node might want a local policy to influence which interface will be used based on various conditions. Some Standards Development Organizations (SDOs) have defined policy-based routing selection mechanisms. For instance, the Access Network Discovery and Selection Function (ANDSF) [TS23.402] provides inter-system routing policies to terminals with both a 3GPP interface and non-3GPP interfaces. However, the routing selection may still be difficult, due to disjoint criteria as discussed in Section 3.8. Moreover, information required to make the right decision may not be available. For instance, interfaces to a lower layer may not provide all required hints concerning the selection (e.g., information on interface quality).
MIFノードが宛先への複数の経路を有することができます。ただし、デフォルトでは、それはインターフェースがその先に使用するのがベストだろうこれに関するあらゆるヒントを持っていません。最初のホップの選択、すなわち、使用するインタフェースに関する決定を行い、いくつかのアクター（例えば、ネットワークオペレータまたはサービスプロバイダ）がルーティングテーブルに影響を与えることができるように、ローカルルーティングポリシーに活用することができます。例えば、そのようなマルチホームノード上のユーザーは、さまざまな条件に基づいて使用されるインタフェースに影響するローカルポリシーをお勧めします。いくつかの標準開発機関（SDOの）ポリシーベースルーティングの選択メカニズムを定義しています。例えば、アクセスネットワーク発見と選択機能（ANDSF）[TS23.402]は3GPPインタフェースと非3GPPの両方のインターフェースを有する端末にシステム間ルーティングポリシーを提供します。セクション3.8で議論するようにしかし、ルーティングの選択は依然としてによる互いに素基準に、困難であり得ます。また、右の決定を行うために必要な情報が利用できない場合があります。例えば、下位レイヤへのインタフェースは、選択（界面品質に例えば、情報）に関する必要なすべてのヒントを提供することができません。
A node usually has a node-scoped routing table. However, a MIF node is connected to multiple provisioning domains; if each of these domains pushes routing policies to the node, then conflicts between policies may happen, and the node has no easy way to merge or reconcile them.
ノードは通常ノードスコープのルーティングテーブルを有しています。しかし、MIFのノードは、複数のプロビジョニング・ドメインに接続されています。これらのドメインの各ノードにルーティングポリシーをプッシュした場合、その後の政策間の競合が発生する可能性があり、かつノードがマージしたり、それらを調整する簡単な方法はありません。
On a MIF node, some source addresses are not valid if used on some interfaces. For example, an [RFC1918] source address might be appropriate on the VPN interface but not on the public interface of the MIF node. If the source address is not chosen appropriately, then packets may be filtered in the path if source address filtering is in place ([RFC2827], [RFC3704]), and reply packets may never come back to the source.
いくつかのインターフェイスで使用される場合MIFノードで、いくつかのソースアドレスは有効ではありません。例えば、[RFC1918]のソースアドレスは、VPNインターフェースではなく、MIFノードのパブリックインターフェイス上で適切であるかもしれません。ソースアドレスが適切に選択されていない場合、パケットは、送信元アドレスフィルタリングが適所にある場合（[RFC2827]、[RFC3704]）パスで濾過し、パケットを返信することができるバックソースに来ないかもしれません。
The distribution of configuration policies (e.g., address selection, routing, DNS selection) to end nodes is being discussed (e.g., ANDSF in [TS23.402], [DHCPv6-ROUTE-OPTIONS]). If implemented in multiple provisioning domains, such mechanisms may conflict and create issues for the multihomed node. Considering a MIF node (M1) with an active interface (I1) connected to a network (N1) and another active interface (I2) connected to a network (N2), the following conflicts may occur:
設定ポリシーノードを終了する（例えば、アドレス選択、ルーティング、DNS選択）の分布が検討されている（例えば、中ANDSF [TS23.402]、[DHCPv6の-ROUTE-OPTIONS]）。複数のプロビジョニングドメインで実施される場合、そのようなメカニズムは、競合とマルチホームノードのための問題を作成することができます。ネットワーク（N1）とネットワーク（N2）に接続された他のアクティブインタフェース（I2）に接続されたアクティブインタフェース（I1）を有するMIFノード（M1）を考慮し、次の競合が発生する可能性があります。
1. M1 receives from both networks (N1 and N2) an update of its default address selection policy. However, the policies are specific to each network. The policies are merged by the M1 stack. Based on the merged policy, the chosen source address is from N1, but packets are sent to N2. The source address is not reachable from N2; therefore, the return packet is lost. Merging address selection policies may have important impacts on routing.
1. M1は、両方のネットワーク（N1及びN2）からデフォルトのアドレス選択ポリシーの更新を受信します。しかし、ポリシーは、各ネットワークに固有のものです。ポリシーは、M1スタックによってマージされます。マージされたポリシーに基づいて、選択した送信元アドレスはN1からですが、パケットがN2に送信されます。送信元アドレスは、N2から到達可能ではありません。そのため、戻りパケットが失われています。マージアドレス選択ポリシーは、ルーティングに重要な影響を有することができます。
2. A node usually has a node-scoped routing table. However, each of the connected provisioning domains (N1 and N2) may push routing policies to the node; conflicts between policies may then happen, and the node has no easy way to merge or reconcile them.
2.ノードは通常ノードスコープのルーティングテーブルを有しています。しかし、接続されたプロビジョニングドメイン（N1及びN2）の各ノードにポリシーをルーティング押してもよいです。ポリシー間の競合は、発生する可能性があり、かつノードがマージしたり、それらを調整する簡単な方法はありません。
3. M1 receives from one of the networks an update of its access selection policy, e.g., via the 3GPP/ANDSF [TS23.402]. However, the policy is in conflict with the local policy (e.g., user-defined or default OS policy). Assuming that the network provides a list of overloaded access networks, if the policy sent by the network is ignored, the packet may be sent to an access network with poor quality of communication.
3. M1は、3GPP / ANDSF [TS23.402]を介して、例えば、ネットワークのいずれかからそのアクセス選択ポリシーの更新を受信します。しかし、ポリシーがローカルポリシー（例えば、ユーザ定義またはデフォルトOSポリシー）と競合しています。ネットワークによって送信されたポリシーが無視される場合、ネットワークは、過負荷アクセスネットワークのリストを提供すると仮定すると、パケット通信の不良な品質でアクセスネットワークに送信することができます。
Consider that a node has selected an interface and managed to configure it (i.e., the node obtained a valid IP address from the network). However, Internet connectivity is not available. The problem could be due to the following reasons:
ノードは、インターフェイスを選択し、それを構成するために管理していると考える（すなわち、ノードは、ネットワークから有効なIPアドレスを得ます）。ただし、インターネット接続が利用できません。問題は、次の理由に起因することができます。
1. The network requires a web-based authentication (e.g., the access network is a WiFi hot spot). In this case, the user can only access a captive portal. For instance, the network may perform HTTP redirection or modify DNS behavior (Section 4.1) until the user has not authenticated.
1.ネットワークは、ウェブベースの認証を必要とする（例えば、アクセス・ネットワークは、WiFiホットスポット）で。この場合、ユーザーはキャプティブポータルにアクセスすることができます。例えば、ネットワークは、HTTPリダイレクトを実行するか、またはユーザが認証されていないまでDNSの動作（セクション4.1）を変更することができます。
2. The IP interface is configured as active, but Layer 2 is so poor (e.g., poor radio condition) that no Layer 3 traffic can succeed.
2. IPインタフェースはアクティブとして構成されるが、レイヤ2には、レイヤ3トラフィックは成功しないことができる（例えば、乏しい無線状態）が貧弱です。
In this situation, the session manager should be able to perform IP connectivity checks before selecting an interface.
このような状況では、セッションマネージャは、インターフェイスを選択する前に、IP接続チェックを実行することができるはずです。
Session issues may also arise when the node discovers a new provisioning domain. Consider a MIF node (M1) with an active interface (I1) connected to a network (N1) where an application is running a TCP session. A new network (N2) becomes available. If N2 is selected (e.g., because of better quality of communication), M1 gets IP connectivity to N2 and updates the routing table priority. So, if no specific route to the correspondent node is in place, and if the node implements the weak host model [RFC1122], the TCP connection breaks as the next hop changes. In order to continue communicating with the correspondent node, M1 should try to reconnect to the server via N2. In some situations, it could be preferable to maintain current sessions on N1 while new sessions start on N2.
ノードは、新しいプロビジョニングドメインを発見した場合、セッションの問題も発生する可能性があります。アプリケーションは、TCPセッションを実行しているネットワーク（N1）に接続されたアクティブインタフェース（I1）を有するMIFノード（M1）を考えます。新網（N2）が利用可能になります。 N2は、（例えば、なぜなら通信のより良い品質の）選択された場合、M1はN2へのIP接続を取得し、ルーティングテーブルの優先度を更新します。だから、コレスポンデントノードへの特定のルートが整備されているいない場合、およびノードが弱いホストモデル[RFC1122]、ネクストホップの変更などのTCPコネクションの切断を実装している場合。コレスポンデントノードとの通信を継続するためには、M1は、N2を介してサーバに再接続しようとする必要があります。いくつかの状況では、新しいセッションがN2に開始しながら、N1の現在のセッションを維持することが好ましいかもしれません。
When a node using a single interface is connected to multiple networks, such as different default routers, similar issues to those described above will happen. Even with a single interface, a node may wish to connect to more than one provisioning domain: that node may use more than one IP source address and may have more than one default router. The node may want to access services that can only be reached using one of the provisioning domains. In this case, it needs to use the right outgoing source address and default gateway to reach that service. In this situation, that node may also need to use different DNS servers to get domain names in those different provisioning domains.
単一のインターフェースを使用して、ノードが、異なるデフォルトルータとして複数のネットワークに接続されている場合、上記と同様の問題が起こります。でも、単一のインタフェースで、ノードは、複数のプロビジョニングドメインに接続したい場合があります。そのノードは、複数の送信元IPアドレスを使用することができますし、複数のデフォルトのルータを有することができます。ノードは、プロビジョニングドメインの1つを使用して到達することができるサービスにアクセスすることもできます。この場合は、そのサービスに到達するために、右の発信元アドレスおよびデフォルトゲートウェイを使用する必要があります。このような状況では、そのノードはまた、これらの異なるプロビジョニングドメインにドメイン名を取得するために別のDNSサーバーを使用する必要があるかもしれません。
This section lists the underlying problems, and their causes, that lead to the issues discussed in the previous section. The problems can be divided into five categories: 1) configuration, 2) DNS resolution, 3) routing, 4) address selection, and 5) session management and APIs. They are shown below:
このセクションでは、前のセクションで説明した問題につながる根本的な問題、およびその原因を、一覧表示されます。 1）構成、2）DNS解決、3）ルーティング、4）アドレス選択、及び5）セッション管理とAPI：問題は、5つのカテゴリーに分けることができます。これらは以下の通りです：
1. Configuration. In a MIF context, configuration information specific to a provisioning domain may be ignored because:
1.設定。 MIFの文脈では、プロビジョニングドメインに固有の設定情報があるため、無視してもよいです。
A. Configuration objects (e.g., DNS servers, NTP servers) are
node-scoped. So, the IP stack is not able to maintain the
mapping between configuration information and the
corresponding provisioning domain.
B. The same configuration objects (e.g., DNS server addresses, NTP server addresses) received from multiple provisioning domains may be overwritten.
B.同じ構成オブジェクト（例えば、DNSサーバアドレス、NTPサーバアドレス）が上書きされる可能性があり、複数のプロビジョニング・ドメインから受け取りました。
C. Host implementations usually do not keep separate network configurations (such as DNS server addresses) per provisioning domain.
C.ホストの実装は通常、ドメインのプロビジョニングごと（例えばDNSサーバアドレスなど）別のネットワーク構成を保持しません。
A. Some FQDNs can be resolvable only by sending queries to the
right server (e.g., intranet services). However, a DNS query
could be sent to the wrong interface because DNS server
addresses may be node-scoped.
B. A DNS answer may be only valid on a specific provisioning domain, but applications may not be aware of that mapping because DNS answers may not be kept with the provisioning from which the answer comes.
B. DNSの答えは、特定のプロビジョニングドメインでのみ有効かもしれないが、DNSの答えは答えが来るからプロビジョニングと一緒に保管されていない可能性があるため、アプリケーションは、そのマッピングを認識しないかもしれません。
A. In the MIF context, routing information could be specific to
each interface. This could lead to routing issues because,
in current node implementations, routing tables are node-
scoped.
B. Current node implementations do not take into account the Differentiated Services Code Point or path characteristics in the routing table.
B.現在のノードの実装は、ルーティングテーブルで考慮に差別化サービスコードポイントまたはパス特性を取ることはありません。
C. Even if implementations take into account path characteristics, the node has no way to properly merge or reconcile the provisioning domain preferences.
C.は、実装は、アカウント路特性を考慮する場合であっても、ノードは正常にマージしたり、プロビジョニングドメインの設定を調整する方法がありません。
D. A node attached to multiple provisioning domains could be provided with incompatible selection policies. If the different actors (e.g., user and network operator) are allowed to provide their own policies, the node has no way to properly merge or reconcile multiple selection policies.
複数のプロビジョニングドメインに取り付けD.ノードは互換性のない選択ポリシーを設けることができます。異なるアクタ（例えば、ユーザとネットワーク事業者）は、独自のポリシーを提供するために許可されている場合、ノードは、適切にマージまたは複数の選択ポリシーを調整する方法がありません。
E. The problem of first-hop selection could not be solved via configuration (Section 3.7), and may leverage on sophisticated and specific mechanisms (Section 3.8).
E.は、最初のホップの選択の問題は、構成（3.7節）を介して解決することができず、洗練された特定のメカニズム（セクション3.8）に活用することができます。
A. Default address selection policies may be specific to their
corresponding provisioning domain. However, a MIF node may
not be able to manage address selection policies per
provisioning domain, because default address selection
policies are node-scoped.
B. On a MIF node, some source addresses are not valid if used on some interfaces or even on some default routers on the same interface. In this situation, the source address should be taken into account in the routing table, but current node implementations do not support such a feature.
いくつかのインターフェイス上または同じインタフェース上でいくつかのデフォルトルータで使用される場合MIFノードでB.は、いくつかのソースアドレスは有効ではありません。このような状況では、送信元アドレスがルーティングテーブルに考慮されるべきであるが、現在のノードの実装では、このような機能をサポートしていません。
C. Source address or address selection policies could be specified by applications. However, there are no advanced APIs that support such applications.
C.ソースアドレスまたはアドレス選択ポリシーは、アプリケーションによって指定することができます。しかし、そのようなアプリケーションをサポートして何の高度なAPIはありません。
A. Some implementations, especially in the mobile world, have
higher-level APIs and/or session managers (aka connection
managers) to address MIF issues. These mechanisms are not
standardized and do not necessarily behave the same way
across different OSes and/or platforms in the presence of MIF
problems. This lack of consistency is an issue for the user
and operator, who could experience different session manager
behaviors, depending on the terminal.
B. Session managers usually leverage on an interface to the link layer to gather information (e.g., lower-layer authentication and encryption methods) and/or for control purposes. However, such a link-layer interface may not provide all required services (e.g., may not provide all information that would allow a proper interface selection).
B.セッションマネージャは、通常（例えば、下層の認証および暗号化の方法）、および/または制御目的のために情報を収集するためにリンク層との界面に活用します。しかしながら、このようなリンク層インターフェースは、すべての必要なサービスを提供しないかもしれない（例えば、適切なインタフェースの選択を可能にする全ての情報を提供しないかもしれません）。
C. A MIF node can support different session managers, which may have contradictory ways of solving MIF issues. For instance, because of different selection algorithms, two different session managers could select different domains in the same context. Or, when dealing with different domain selection policies, one session manager may give precedence to user policy while another could favor mobile operator policy.
C. A MIFノードは、MIFの問題を解決する矛盾した方法を有していてもよい、別のセッションマネージャをサポートすることができます。例えば、なぜなら異なる選択アルゴリズムの、二つの異なるセッション・マネージャは、同じコンテキスト内の異なるドメインを選択することができます。異なるドメイン選択ポリシーを扱うときに、別の携帯電話事業者の方針を支持する可能性がありながら、または、1つのセッションマネージャは、ユーザポリシーに優先権を与えることができます。
D. When host routing is updated and if the weak host model is supported, ongoing TCP sessions may break if routes change for these sessions. When TCP sessions should be bound to the interface, the strong host model should be used.
D.は、ホストルーティングが更新されると、弱いホストモデルがサポートされている場合ルートは、これらのセッションのために変更した場合、現在進行中のTCPセッションが壊れることがあります。 TCPセッションがインターフェイスにバインドする必要がある場合には、強力なホストモデルを使用する必要があります。
E. When provided by different actors (e.g., user, network, default OS), policies may conflict and, thus, need to be reconciled at the host level. Policy conflict resolution may impact other functions (e.g., naming, routing).
異なるアクタ（例えば、ユーザ、ネットワーク、デフォルトOS）によって提供される場合、Eは、ポリシーが競合する可能性があり、従って、ホストレベルで両立する必要があります。ポリシー競合解決は、他の機能（例えば、ネーミング、ルーティング）影響を与える可能性があります。
F. Even if the node has managed to configure an interface, Internet connectivity could be unavailable. This could be due to an access control function coming into play above Layer 3, or because of poor Layer 2 conditions. An IP connectivity check should be performed before selecting an interface.
F.は、ノードがインターフェイスを設定するために管理している場合でも、インターネット接続が利用できない可能性があります。これは、レイヤ3の上方に遊びに来たアクセス制御機能に起因するもの、または悪いため、レイヤ2の条件の可能性があります。 IP接続性チェックは、インターフェースを選択する前に実行する必要があります。
The problems discussed in this document have security implications, such as when packets sent on the wrong interface might be leaking some confidential information. Configuration parameters from one provisioning domain could cause a denial of service on another provisioning domain (e.g., DNS issues). Moreover, the undetermined behavior of IP stacks in the multihomed context brings additional threats where an interface on a multihomed node might be used to conduct attacks targeted to the networks connected by the other interfaces. Corrupted provisioning domain selection policy may induce a node to make decisions causing certain traffic to be forwarded to the attacker.
この文書で説明する問題は、このような誤ったインターフェイス上で送信されたパケットは、いくつかの機密情報の漏洩する可能性がある場合など、セキュリティへの影響を、持っています。 1つのプロビジョニングドメインから構成パラメータは、別のプロビジョニングドメイン（例えば、DNSの問題）にサービス拒否を引き起こす可能性があります。また、マルチホームのコンテキストにおけるIPスタックの不確定動作は、マルチホームノード上のインターフェイスは、他のインタフェースによって接続されたネットワークを標的とする攻撃を行うために使用されるかもしれない付加的な脅威をもたらします。破損したプロビジョニングドメイン選択ポリシーは、攻撃者に転送されるように、特定のトラフィックを引き起こして意思決定を行うためにノードを誘導することができます。
Additional security concerns are raised by possible future mechanisms that provide additional information to the node so that it can make a more intelligent decision with regards to the issues discussed in this document. Such future mechanisms may themselves be vulnerable and may not be easy to protect in the general case.
それは、この文書で議論された問題に関してで、よりインテリジェントな意思決定を行うことができるように、追加のセキュリティ上の懸念は、ノードへの追加情報を提供することができ、将来のメカニズムによって提起されています。そのような将来のメカニズム自体が脆弱であり、一般的なケースで保護することは容易ではないかもしれません。
This document is a joint effort with the authors of the MIF requirements document [MIF-REQ]. This includes, in alphabetical order: Jacni Qin, Carl Williams, and Peng Yang.
この文書では、MIFの要件ドキュメント[MIF-REQ]の著者との共同の努力です。これは、アルファベット順に、Jacni秦、カール・ウィリアムズ、そしてパン・ヤンが。
The documents written prior to the existence of the MIF working group, and the discussions during the MIF Birds of a Feather (BOF) meeting and around the MIF charter scope on the mailing list, brought very good input to the problem statement. This document steals a lot of text from these discussions and initial documents (e.g., [MIF-REQ], [IP-MULTIPLE-CONN], [MIF-DNS-SERVER-SELECT]). Therefore, the authors would like to acknowledge the following people (in no specific order), from whom some text has been taken: Jari Arkko, Keith Moore, Sam Hartman, George Tsirtsis, Scott Brim, Ted Lemon, Bernie Volz, Giyeong Son, Gabriel Montenegro, Julien Laganier, Teemu Savolainen, Christian Vogt, Lars Eggert, Margaret Wasserman, Hui Deng, Ralph Droms, Ted Hardie, Christian Huitema, Remi Denis-Courmont, Alexandru Petrescu, Zhen Cao, Gaetan Feige, Telemaco Melia, and Juan-Carlos Zuniga. Apologies to any contributors who have inadvertently not been named.
フェザー（BOF）会議やメーリングリストのMIFのチャーター範囲の周りのMIF鳥の間に前MIFワーキンググループの存在、およびディスカッションに書かれた文書は、問題文のに非常に優れた入力をもたらしました。この文書では、これらの議論と、最初の文書からテキストの多くを盗む（例えば、[MIF-REQ]、[IP-MULTIPLE-CONN]、[MIF-DNS-SERVER-SELECT]）。そこで、著者らは、いくつかのテキストがとられている誰から次の人（なし特定の順序で）、承認したいと思います：ヤリArkko、キースムーア、サム・ハートマン、ジョージTsirtsis、スコット・ブリム、テッド・レモン、バーニーフォルツ、Giyeong息子を、ガブリエルモンテネグロ、ジュリアンLaganier、テームSavolainenの、クリスチャン・フォークト、ラースEggertの、マーガレットワッサーマン、ホイトウ氏、ラルフDroms、テッドハーディー、クリスチャンのHuitema、レミデニス・Courmont、アレクサンドル・ペトレスク、ジェン曹操、ガエタンFeige、Telemacoメリア、およびJuan-カルロス・スニガ。うっかり命名されていないすべての貢献者に謝罪。
[ADDR-SELECT-SOL] Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution approaches for address-selection problems", Work in Progress, March 2010.
[ADDR-SELECT-SOL]松本、A.、藤崎、T.、およびR.ひろみは、進歩、2010年3月の作業 "ソリューションは、アドレス選択問題のためのアプローチ"。
[DHCPv6-ROUTE-OPTIONS] Dec, W., Ed., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6 Route Options", Work in Progress, September 2011.
[DHCPv6の-ROUTE-OPTIONS] 12月、W.、エド。、Mrugalski、T.、日、T.、およびB. Sarikaya、 "DHCPv6のルートオプション"、進歩、2011年9月での作業。
[IP-MULTIPLE-CONN] Hui, M. and H. Deng, "Problem Statement and Requirement of Simple IP Multi-homing of the Host", Work in Progress, March 2009.
[IP-MULTIPLE-CONN]ホイ、M.およびH.鄧小、「ホストのシンプルIPマルチホーミングの問題文と要件」、進歩、2009年3月に作業。
[LOGICAL-IF-SUPPORT] Melia, T., Ed., and S. Gundavelli, Ed., "Logical Interface Support for multi-mode IP Hosts", Work in Progress, October 2011.
[LOGICAL-IF-SUPPORT]メリア、T.、エド。、およびS. Gundavelli、エド。、 "マルチモードIPホストの論理インターフェイスのサポート"、進歩、2011年10月での作業。
[MIF-DNS-SERVER-SELECT] Savolainen, T., Kato, J., and T. Lemon, "Improved DNS Server Selection for Multi-Interfaced Nodes", Work in Progress, October 2011.
[MIF-DNS-SERVER-SELECT] Savolainenの、T.、加藤、J.、およびT.レモン、 "マルチ式インタフェースノードの改善されたDNSサーバーの選択"、進歩、2011年10月での作業。
[MIF-REQ] Yang, P., Seite, P., Williams, C., and J. Qin, "Requirements on multiple Interface (MIF) of simple IP", Work in Progress, February 2009.
"シンプルIPの複数のインタフェース上の要件（MIF）" [MIF-REQ]ヤン、P.、Seite、P.、ウィリアムズ、C.、およびJ.秦、進歩、2009年2月作業。
[MIH] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Part 21: Media Independent Handover Services", IEEE LAN/MAN Std. 802.21-2008, January 2009.
[MIH] IEEE、 "地方とメトロポリタンエリアネットワークのIEEE規格 - パート21：メディア独立ハンドオーバサービス"、IEEE LAN / MAN STD。 802.21から2008、2009年1月。
[REFERRAL-PS] Carpenter, B., Jiang, S., and Z. Cao, "Problem Statement for Referral", Work in Progress, February 2011.
[参照-PS]大工、B.、江、S.、およびZ.曹操、 "紹介のための問題文"、進歩、2011年2月に作業。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、エド、 "インターネットホストのための要件 - 通信層"。、STD 3、RFC 1122、1989年10月。
[RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing Domains: A model for routing in the Internet", RFC 1136, December 1989.
[RFC1136]野兎、S.及びD.カッツ、「管理ドメインとルーティングドメイン：インターネットにルーティングするためのモデル」、RFC 1136、1989年12月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、編、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス攻撃の敗北拒否"、BCP 38、RFC 2827、2000年5月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、編、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315 、2003年7月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003.
"IPv6用の拡張ソケットアプリケーション・プログラム・インターフェース（API）" [RFC3542]スティーブンス、W.、トーマス、M.、Nordmarkと、E.、およびT.神明、RFC 3542、2003年5月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.およびP. Savola、 "マルチホームネットワークの入力フィルタリング"、BCP 84、RFC 3704、2004年3月。
[RFC4294] Loughney, J., Ed., "IPv6 Node Requirements", RFC 4294, April 2006.
[RFC4294] Loughney、J.、エド。、 "IPv6のノードの要件"、RFC 4294、2006年4月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、エド。、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007.
[RFC5014] Nordmarkと、E.、Chakrabarti、S.、およびJ. Laganier、 "ソースアドレス選択のIPv6ソケットAPI"、RFC 5014、2007年9月。
[RFC5113] Arkko, J., Aboba, B., Korhonen, J., Ed., and F. Bari, "Network Discovery and Selection Problem", RFC 5113, January 2008.
[RFC5113] Arkko、J.、Aboba、B.、Korhonen、J.、エド。、およびF.バーリ、 "ネットワーク探索と選択問題"、RFC 5113、2008年1月。
[RFC5206] Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206] Nikander、P.、ヘンダーソン、T.、エド。、フォークト、C.、およびJ. Arkko、 "エンドホストモビリティとマルチホーミングをホストアイデンティティプロトコルで"、RFC 5206、2008年4月。
[RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, "Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules", RFC 5220, July 2008.
[RFC5220]松本、A.、藤崎、T.、ひろみ、R.、およびK.金山、「マルチプレフィックス環境でのデフォルトアドレス選択の問題文：RFC 3484のデフォルトのルールの運用上の問題」、RFC 5220、2008年7月。
[RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, "Requirements for Address Selection Mechanisms", RFC 5221, July 2008.
[RFC5221]松本、A.、藤崎、T.、ひろみ、R.、およびK.金山、 "アドレス選択メカニズムのための要件"、RFC 5221、2008年7月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]ローゼンバーグ、J.、 "インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書"、RFC 5245、2010年4月。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5533] Nordmarkと、E.およびM. Bagnulo、 "SHIM6：IPv6のレベル3マルチホーミングシム・プロトコル"、RFC 5533、2009年6月。
[RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009.
[RFC5648] Wakikawa、R.、エド。、Devarapalli、V.、Tsirtsis、G.、エルンスト、T.、およびK.永見、 "複数の気付アドレスの登録"、RFC 5648、2009年10月。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC6147] Bagnulo、M.、サリバン、A.、マシューズ、P.、およびI.バンBeijnum、 "DNS64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレス変換のためのDNS拡張機能"、RFC 6147、2011年4月。
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011.
[RFC6182]フォード、A.、Raiciu、C.、ハンドレー、M.、バール、S.、およびJ.アイアンガー、 "マルチパスTCP開発のための建築ガイドライン"、RFC 6182、2011年3月。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]パーキンス、C.、エド。、ジョンソン、D.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 6275、2011年7月。
[RFC6316] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, Ed., "Sockets Application Program Interface (API) for Multihoming Shim", RFC 6316, July 2011.
[RFC6316]こむ、M.、Bagnulo、M.、Slavov、K.、およびS.杉本、編、 "ソケットアプリケーション・プログラム・インターフェース（API）マルチホーミングシム用"、RFC 6316、2011年7月。
[RFC6419] Wasserman, M. and P. Seite, "Current Practices for Multiple-Interface Hosts", RFC 6419, November 2011.
[RFC6419]ワッサーマン、M.とP. Seite、 "複数のインタフェースのホストの現在のプラクティス"、RFC 6419、2011年11月。
[SHIM6-APP-REFER] Nordmark, E., "Shim6 Application Referral Issues", Work in Progress, July 2005.
[SHIM6-APP-REFER] Nordmarkと、E.、 "SHIM6アプリケーションの紹介の問題"、進歩、2005年7月での作業。
[TS23.234] 3GPP, "3GPP system to Wireless Local Area Network (WLAN) interworking", TS 23.234, December 2009.
、TS 23.234、2009年12月 "ワイヤレスローカルエリアネットワーク（WLAN）インターワーキングへの3GPPシステム" [TS23.234] 3GPP、。
[TS23.402] 3GPP, "Architecture enhancements for non-3GPP accesses", TS 23.402, December 2010.
[TS23.402] 3GPP、TS 23.402、2010年12月 "非3GPPのためのアーキテクチャの機能拡張アクセス"。
Authors' Addresses
著者のアドレス
Marc Blanchet Viagenie 2875 boul. Laurier, suite D2-630 Quebec, QC G1V 2M2 Canada
マルク・ブランシェViagénie2875 BOUL。ローリエ、スイートD2-630ケベック、QC G1V 2M2カナダ
EMail: Marc.Blanchet@viagenie.ca URI: http://viagenie.ca
電子メール：Marc.Blanchet@viagenie.ca URI：http://viagenie.ca
Pierrick Seite France Telecom - Orange 4, rue du Clos Courtel, BP 91226 Cesson-Sevigne 35512 France
Pierrick Seiteフランステレコム - オレンジ4ルードゥクロCourtel、BP 91226 35512セッソンセビニェフランス
EMail: pierrick.seite@orange.com
メールアドレス：pierrick.seite@orange.com