[要約] RFC 6418は、複数のインターフェースとプロビジョニングドメインの問題に関する声明です。その目的は、異なるネットワークインターフェースとプロビジョニングドメインの間での通信の問題を解決することです。
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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セルネットワーク、1つまたは複数の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アドレス、異なるデフォルトゲートウェイ、または異なるアドレス選択ポリシーなど、各プロビジョニングドメインとは異なる値を持つ場合、ノードは使用するもの、またはそれらをマージする方法を決定する必要があります。
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バージョンを参照することなく、このドキュメントでIP、PPP、DHCPなどのプロトコルキーワードが使用される場合、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]で定義されている下層のネットワークの発見と選択は、このドキュメントの範囲外です。さらに、IEEE 802.21で定義されているサービスなどの低層メカニズムとの相互運用性は、異種ネットワーク[MIH]間のハンドオーバーを促進することを目的としていますが、範囲外です。
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.
o MIFノードは、IPスタックに表示されるように、複数のプロビジョニングドメインに接続できます。
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.
o これらのIPアドレスを使用している通信は、すべてのプロビジョニングドメインで可能ですが、プロビジョニングドメインの小さいセットでのみ可能です。
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.
o MIFノードはインターフェイス間でパケットを転送できますが、パケットの転送はこの定義では考慮されておらず、このドキュメントの範囲外です。
"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.
「インターネットホストの要件 - 通信レイヤー」[RFC1122]は、複数のIPアドレスがあるかのようにマルチホームノードを説明します。これは、同じまたは異なるネットワークに接続された1つ以上の物理インターフェイスに関連付けられている可能性があります。
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アドレス、宛先IPアドレス、サービスのタイプ（差別化されたサービスコードポイント[RFC2474]に取って代わる）が含まれるルートキャッシュテーブルを維持していることを示しています。次のホップゲートウェイ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.
Multihomedノードは、モデルに応じて、発信データグラムのルートを異なります。強力なモデルでは、ルートはソース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].
このドキュメントの範囲は、輸送層、モビリティ、マルチホミング、または識別子ロケーター分割メカニズムの特別なサポートを持たないIPv4に[RFC1122]および[RFC4294]を実装するノードに関するものです。このようなメカニズムを備えた複数のインターフェイスを扱うことは関連していますが、別の問題と考えられており、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.
アプリケーションが1つのインターフェイスを使用しているときに、より良い特性を持つ別のインターフェイスが利用可能になると、継続的なアプリケーションセッションを新しく有効なインターフェイスに転送できます。ただし、場合によっては、新しいインターフェイスで新しいセッションを開始しながら、進行中のセッションを現在のインターフェースに保持するものとします。インターフェイスの選択の問題は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-rect-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.
Interactive Connectivity Indecivity（ICE）[RFC5245]は、オファー/回答モデルによって確立されたUDPベースの（およびTCPベースの）メディアストリームのNATトラバーサルの手法です。セッション説明プロトコル（SDP）オファーのIPアドレス、ポート、および輸送メカニズムの多様性は、ピアツーピア接続のチェックによって接続性をテストします。その結果、他のピアとの接続を確立するための候補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-REFER]で説明されています。
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 ラジオリンクの品質
o network resource considerations (e.g., available Quality of Service (QoS), IP connectivity check)
o ネットワークリソースの考慮事項（例：利用可能なサービス品質（QOS）、IP接続チェック）
o the application QoS requirements in order to map applications to the best interface
o アプリケーションを最適なインターフェイスにマップするためのアプリケーションQoS要件
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.
特にモバイルの世界でのいくつかの実装は、複数のプロビジョニングドメインに同時に添付されている問題に対処するために、Connection Managerとも呼ばれる高レベルのセッションマネージャーに依存しています。通常、セッションマネージャーは、アプリケーションに代わって、インターフェイスおよび/またはプロビジョニングドメインの選択、または矛盾するポリシーを解決する方法などの複雑な問題に取り組むことができます（セクション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ネットワーク[Logical-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]は、Advanced Sockets APIを使用したアプリケーションが、単純なbind（）操作または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.
MIFと同様の問題を解決するために、他のAPIが定義されています。たとえば、[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つのインターフェイスはインターネット上にあり、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. 1つのインターフェイスは1つのアクセスネットワーク（つまり、WiFi）にあり、もう1つのインターフェイスは特定のサービスを備えた別のアクセスネットワーク（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
MIFノード（M1）には、ネットワーク（N1）に接続されたアクティブインターフェイス（I1）があり、DNSサーバー（プライマリDNSサーバーとしてS1）とネットワーク（N2）に接続された別のアクティブインターフェイス（I2）があります。そのDNSサーバー（プライマリDNSサーバーとしてのS2）。S1はプライベートにサービスを提供しています
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:
名前空間、「private.example.com」。ユーザーまたはアプリケーションは、「a.private.example.com」という名前を使用します。これは、S1のプライベートネームスペース内で、S1によってのみ解決可能です。次の状況のいずれかが発生する可能性があります。
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スタックは、i2を使用してS1に到達し、「a.private.example.com」を解決します。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サーバーアドレスのセットのみを保持します。M1がS2のアドレスをプライマリDNSサーバーとして保持していると仮定しましょう。M1は、a.private.example.comのフォワードDNSクエリをS2に送信します。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サーバーアドレスのセットのみを保持します。M1がS2のアドレスを保持していると仮定しましょう。M1は、a.private.example.comのDNSクエリをS2に送信します。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は、[a.private.example.com]を[RFC1918]アドレスに解決するために使用されています。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.
5. M1は、N1に接続すると、完全に適格なドメイン名（FQDN）をローカル有効なIPアドレスに解決しました。ノードがN1への接続を失った場合、ノードはN2を介して以前と同じIPアドレスに接続しようとする場合がありますが、アドレスはローカルでのみ有効であるため、接続セットアップは失敗します。同様に、M1はN1に接続すると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.
6. 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:
一部のネットワークでは、インターネット接続を提供する前に、ユーザーがCaptive Webポータルで認証する必要があります。このリダイレクトがDNS応答を変更することで達成されると、特定の問題が発生する可能性があります。DNSサーバー（S1）を備えたネットワーク（N1）に接続されたアクティブインターフェイス（I1）と、DNSを持つネットワーク（N2）に接続された別のアクティブインターフェイス（I2）を備えたMIFノード（M1）を考えてみましょうサーバー（S2）。ユーザーが認証されなくなるまで、S1は、Access ControlポータルWebページにWebブラウザーをリダイレクトするために、CaptiveポータルのIPアドレスを使用してAまたはAAAAレコードクエリに応答するように構成されています。このキャプティブポータルは、I1を介してのみ到達できます。ユーザーがキャプティブポータルに認証された場合、M1はN1に接続すると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サーバーアドレスのセットのみを保持し、S2アドレスを保持します。M1は、a.example.comのフォワードDNSクエリをS2に送信します。S2は正解、R1で応答します。M1はI1を経由してR1に接触しようとします。接続に失敗します。または、接続が成功し、N1のセキュリティポリシーをバイパスし、M1の所有者を検察にさらしている可能性があります。
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サーバーアドレスのセットのみを保持し、S1アドレスを保持します。M1は、a.example.comのDNSクエリをS1に送信します。S1は、キャプティブポータルのアドレスを提供します。M1は、I1を使用してこのIPアドレスに連絡しようとします。アプリケーションが接続できず、サービスが不足しています。または、アプリケーションは接続に成功しますが、意図した宛先ではなくキャプティブポータルに接続するため、サービスが不足しています（つまり、セクション4.4で説明されているように、IP接続チェックの問題）。
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）に接続されたアクティブインターフェイス（I1）とネットワーク（N2）に接続された別のアクティブインターフェイス（I2）を備えた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.
1. IP1の場合、M1にはネットワーク（N1）を介して1つのデフォルトルート（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.
2. IP1アドレスファミリの場合、M1にはネットワークごとに1つのデフォルトルート（R1、R2）があります（N1、N2）。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.
3. IP1アドレスファミリの場合、M1にはデフォルトルート（R1）、特定のx.0.0.0/8ルートR1B（たとえば、[RFC1918]プレフィックスに限定されていません）、およびデフォルトのルート（R2）があります。N2へ。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選択）の分布について説明します（例：[TS23.402]、[DHCPV6-Route-Options]）。複数のプロビジョニングドメインに実装されている場合、そのようなメカニズムは競合し、マルチホームノードの問題を作成する可能性があります。ネットワーク（N1）に接続されたアクティブインターフェイス（I1）とネットワーク（N2）に接続された別のアクティブインターフェイス（I2）を備えた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は、ネットワークの1つから、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. ネットワークには、Webベースの認証が必要です（たとえば、アクセスネットワークは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ソースアドレスを使用し、複数のデフォルトルーターを使用する場合があります。ノードは、プロビジョニングドメインのいずれかを使用してのみ到達できるサービスにアクセスすることをお勧めします。この場合、そのサービスに到達するには、正しい発信ソースアドレスとデフォルトゲートウェイを使用する必要があります。この状況では、そのノードは、異なる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:
このセクションでは、前のセクションで説明した問題につながる根本的な問題とその原因をリストします。問題は、5つのカテゴリに分類できます。1）構成、2）DNS解像度、3）ルーティング、4）アドレス選択、および5）セッション管理とAPI。以下に示します：
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.
A.構成オブジェクト（例：DNSサーバー、NTPサーバー）はノードスコープです。したがって、IPスタックは、構成情報と対応するプロビジョニングドメイン間のマッピングを維持できません。
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サーバーアドレスなど）を維持しません。
2. DNS resolution
2. 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.
A.一部のFQDNは、適切なサーバーにクエリを送信することによってのみ解決できます（例：イントラネットサービス）。ただし、DNSサーバーアドレスがノードスコープである可能性があるため、DNSクエリを間違ったインターフェイスに送信できます。
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の回答は回答が来るプロビジョニングで保持されないため、アプリケーションはそのマッピングに気付いていない場合があります。
3. Routing
3. ルーティング
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.
A. MIFコンテキストでは、ルーティング情報は各インターフェイスに固有の場合があります。現在のノードの実装では、ルーティングテーブルがノードスコープされているため、これはルーティングの問題につながる可能性があります。
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）を活用することができます。
4. Address selection
4. アドレス選択
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.
A.デフォルトのアドレス選択ポリシーは、対応するプロビジョニングドメインに固有の場合があります。ただし、デフォルトのアドレス選択ポリシーがノードスコープされているため、MIFノードはプロビジョニングドメインごとにアドレス選択ポリシーを管理できない場合があります。
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.
B. MIFノードでは、一部のインターフェイスまたは同じインターフェイス上の一部のデフォルトルーターでも使用されている場合、一部のソースアドレスは無効です。この状況では、ソースアドレスをルーティングテーブルで考慮する必要がありますが、現在のノードの実装はそのような機能をサポートしていません。
C. Source address or address selection policies could be specified by applications. However, there are no advanced APIs that support such applications.
C.ソースアドレスまたはアドレス選択ポリシーは、アプリケーションによって指定できます。ただし、そのようなアプリケーションをサポートする高度なAPIはありません。
5. Session management and APIs
5. セッション管理と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.
A.特にモバイルの世界では、MIFの問題に対処するための高レベルのAPIおよび/またはセッションマネージャー（別名接続マネージャー）があります。これらのメカニズムは標準化されておらず、MIF問題の存在下で異なるOSやプラットフォームで必ずしも同じように動作するわけではありません。この一貫性の欠如は、端末に応じて、さまざまなセッションマネージャーの動作を経験できるユーザーとオペレーターにとって問題です。
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. MIFノードは、さまざまなセッションマネージャーをサポートできます。これは、MIFの問題を解決する矛盾した方法がある場合があります。たとえば、選択アルゴリズムが異なるため、2つの異なるセッションマネージャーが同じコンテキストで異なるドメインを選択できます。または、異なるドメイン選択ポリシーを扱う場合、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).
E.異なるアクター（ユーザー、ネットワーク、デフォルトOSなど）によって提供される場合、ポリシーは競合する可能性があり、したがって、ホストレベルで調整する必要があります。ポリシーの競合解決は、他の機能に影響を与える可能性があります（例：命名、ルーティング）。
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.
このドキュメントで議論されている問題には、間違ったインターフェイスに送信されたパケットがいくつかの機密情報を漏らしている可能性があるなど、セキュリティに影響があります。あるプロビジョニングドメインからの構成パラメーターは、別のプロビジョニングドメイン（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 Qin、Carl Williams、Peng Yangがアルファベット順に含まれます。
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.
MIFワーキンググループの存在の前に書かれた文書、およびMIF Birds of a Feather（BOF）会議およびメーリングリストのMIFチャータースコープの周りでの議論は、問題の声明に非常に良いインプットをもたらしました。このドキュメントは、これらの議論と初期ドキュメントから多くのテキストを盗みます（例：[MIF-REQ]、[IP-Multiple-Conn]、[MIF-DNS-Server-Select]）。したがって、著者は、Jari Arkko、Keith Moore、Sam Hartman、George Tsirtsis、Scott Brim、Ted Lemon、Bernie Volz、Giyeong Son、次のテキストが撮影された次の人々（特定の順序で）を認めたいと考えています。ガブリエル・モンテネグロ、ジュリエン・ラガニエ、ティーム・サヴォラーネン、クリスチャン・フォグト、ラース・エガート、マーガレット・ワッサーマン、フイ・デン、ラルフ・ドロムズ、テッド・ハーディ、クリスチャン・フイテマ、レミ・デニス・コースモント、アレクサンドル・ペトレシュ、Zhen CAO、ガエタン・フェイジー、カルロス・ズニガ。誤って名前が付けられていない貢献者に謝罪します。
[ADDR-SELECT-SOL] Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution approaches for address-selection problems", Work in Progress, March 2010.
[Addr-Select-Sol] Matsumoto、A.、Fujisaki、T。、およびR. Hiromi、「住所選択の問題に対するソリューションアプローチ」、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] Dec、W.、ed。、Mrugalski、T.、Sun、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] Hui、M。およびH. Deng、「ホストの単純な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] Melia、T.、ed。、およびS. Gundavelli ed。、「マルチモード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.、Kato、J。、およびT. Lemon、「マルチインターフェイスノードの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.
[Mif-req] Yang、P.、Seite、P.、Williams、C。、およびJ. Qin、「単純なIPの複数のインターフェイス（MIF）の要件」、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] Carpenter、B.、Jiang、S。、およびZ. Cao、「紹介の問題声明」、2011年2月の作業。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R.、ed。、「インターネットホストの要件 - 通信レイヤー」、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] Hares、S。およびD. Katz、「管理ドメインとルーティングドメイン：インターネットでのルーティングのモデル」、RFC 1136、1989年12月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] Simpson、W.、ed。、「ポイントツーポイントプロトコル（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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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.セニー、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、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.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6のダイナミックホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003.
[RFC3542] Stevens、W.、Thomas、M.、Nordmark、E。、およびT. Jinmei、「IPv6用Advanced Socketsアプリケーションプログラムインターフェイス（API）」、RFC 3542、2003年5月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704] Baker、F。およびP. Savola、「マルチホームネットワークのイングレスフィルタリング」、BCP 84、RFC 3704、2004年3月。
[RFC4294] Loughney, J., Ed., "IPv6 Node Requirements", RFC 4294, April 2006.
[RFC4294] Loughney、J.、ed。、「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.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、ed。、「Stream Control Transmission Protocol」、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.、Ed。、およびF. Bari、「ネットワーク発見と選択問題」、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.、Henderson、T.、Ed。、Vogt、C.、およびJ. Arkko、「ホストIDプロトコルを使用したエンドホストモビリティとマルチホミング」、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] Matsumoto、A.、Fujisaki、T.、Hiromi、R。、およびK. Kanayama、「マルチプレフィックス環境でのデフォルトアドレス選択の問題声明：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] Matsumoto、A.、Fujisaki、T.、Hiromi、R。、およびK. Kanayama、「住所選択メカニズムの要件」、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] Rosenberg、J。、「Interactive Connectivity Indecivity（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.、ed。、Devarapalli、V.、Tsirtsis、G.、Ernst、T。、およびK. Nagami、「複数のアドレスの登録」、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.、Sullivan、A.、Matthews、P。、およびI. Van Beijnum、 "DNS64：IPv6クライアントからIPv4サーバーへのネットワークアドレス変換の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] Ford、A.、Raiciu、C.、Handley、M.、Barre、S.、およびJ. Iyengar、「MultiPath TCP開発のための建築ガイドライン」、RFC 6182、2011年3月。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275] Perkins、C.、ed。、Johnson、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] Komu、M.、Bagnulo、M.、Slavov、K。、およびS. Sugimoto、ed。、「Sockets Application Program Interface（API）Multihoming Shim for RFC 6316、2011年7月。
[RFC6419] Wasserman, M. and P. Seite, "Current Practices for Multiple-Interface Hosts", RFC 6419, November 2011.
[RFC6419] Wasserman、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.
[TS23.234] 3GPP、「3GPPシステムからワイヤレスローカルエリアネットワーク（WLAN）インターワーキング」、TS 23.234、2009年12月。
[TS23.402] 3GPP, "Architecture enhancements for non-3GPP accesses", TS 23.402, December 2010.
[TS23.402] 3GPP、「非3GPPアクセスのアーキテクチャ強化」、TS 23.402、2010年12月。
Authors' Addresses
著者のアドレス
Marc Blanchet Viagenie 2875 boul. Laurier, suite D2-630 Quebec, QC G1V 2M2 Canada
Marc Blanchet Viagenie 2875 Boul。ローリエ、スイートD2-630ケベック、QC G1V 2M2カナダ
EMail: 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 France Telecom -Orange 4、Rue Du Clos Courtel、BP 91226 Cesson -Sevigne 35512 France
EMail: pierrick.seite@orange.com