Internet Engineering Task Force (IETF) M. Wasserman
Request for Comments: 6419 Painless Security, LLC
Category: Informational P. Seite
ISSN: 2070-1721 France Telecom - Orange
November 2011
Current Practices for Multiple-Interface Hosts
Abstract
抽象
An increasing number of hosts are operating in multiple-interface environments. This document summarizes current practices in this area and describes in detail how some common operating systems cope with challenges that ensue from this context.
ホストの増加は、複数のインターフェイス環境で動作しています。この文書では、この分野での現在の慣行を要約し、いくつかの一般的なオペレーティング・システムは、この文脈から続いて起こる課題に対処する方法を詳細に説明しています。
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/rfc6419.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6419で取得することができます。
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. Summary of Current Approaches . . . . . . . . . . . . . . . . 3
2.1. Centralized Connection Management . . . . . . . . . . . . 3
2.2. Per-Application Connection Settings . . . . . . . . . . . 4
2.3. Stack-Level Solutions to Specific Problems . . . . . . . . 4
2.3.1. DNS Resolution Issues . . . . . . . . . . . . . . . . 5
2.3.2. First-Hop Selection . . . . . . . . . . . . . . . . . 5
2.3.3. Address Selection Policy . . . . . . . . . . . . . . . 5
3. Current Practices in Some Operating Systems . . . . . . . . . 6
3.1. Mobile Handset Operating Systems . . . . . . . . . . . . . 6
3.1.1. Nokia S60 3rd Edition, Feature Pack 2 . . . . . . . . 7
3.1.2. Microsoft Windows Mobile and Windows Phone 7 . . . . . 9
3.1.3. RIM BlackBerry . . . . . . . . . . . . . . . . . . . . 10
3.1.4. Google Android . . . . . . . . . . . . . . . . . . . . 11
3.1.5. Qualcomm Brew . . . . . . . . . . . . . . . . . . . . 12
3.1.6. Leadcore Technology Arena . . . . . . . . . . . . . . 13
3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 14
3.2.1. Microsoft Windows . . . . . . . . . . . . . . . . . . 14
3.2.1.1. First-Hop Selection . . . . . . . . . . . . . . . 14
3.2.1.2. Outbound and Inbound Addresses . . . . . . . . . . 14
3.2.1.3. DNS Configuration . . . . . . . . . . . . . . . . 15
3.2.2. Linux and BSD-Based Operating Systems . . . . . . . . 16
3.2.2.1. First-Hop Selection . . . . . . . . . . . . . . . 16
3.2.2.2. Outbound and Inbound Addresses . . . . . . . . . . 16
3.2.2.3. DNS Configuration . . . . . . . . . . . . . . . . 17
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . . 19
Multiple-interface hosts face several challenges not faced by single-interface hosts, some of which are described in the multiple interfaces (MIF) problem statement [RFC6418]. This document summarizes how current implementations deal with the problems identified in the MIF problem statement.
マルチインターフェイスホストは複数のインタフェース（MIF）問題文[RFC6418]に記載されているいくつかは単一インタフェースホストによって直面しないいくつかの課題に直面しています。このドキュメントは、現在の実装では、MIFの問題文で特定された問題に対処する方法をまとめたものです。
Publicly available information about the multiple-interface solutions implemented in some widely used operating systems, including both mobile handset and desktop operating systems, is collected in this document, including Nokia S60 [S60], Microsoft Windows Mobile [WINDOWSMOBILE], Blackberry [BLACKBERRY], Google Android [ANDROID], Microsoft Windows, Linux, and BSD-based operating systems.
携帯電話とデスクトップオペレーティングシステムの両方を含む、いくつかの広く使われているオペレーティング・システムに実装され、複数のインターフェイス・ソリューションについての公開情報は、NokiaのS60 [S60]は、MicrosoftのWindows Mobile [WINDOWSMOBILE]、ブラックベリー[ブラックベリー]を含め、本文書に回収されます、GoogleのAndroid [アンドロイド]、マイクロソフトのWindows、Linux、およびBSDベースのオペレーティングシステム。
This section summarizes current approaches that are used to resolve the multiple-interface issues described in the MIF problem statement [RFC6418]. These approaches can be broken down into three major categories:
このセクションでは、MIFの問題文[RFC6418]で説明した複数のインターフェイスの問題を解決するために使用されている現在のアプローチをまとめました。これらのアプローチは、次の3つのカテゴリに分けることができます。
o Centralized connection management
Oの集中接続管理
o Per-application connection settings
Oアプリケーションごとの接続設定
o Stack-level solutions to specific problems
特定の問題に対するOスタックレベルのソリューション
It is a common practice for mobile handset operating systems to use a centralized connection manager that performs network interface selection based on application or user input. However, connection managers usually restrict the problem to the selection of the interface and do not cope with selection of the provisioning domain, as defined in [RFC6418]. The information used by the connection manager may be programmed into an application or provisioned on a handset-wide basis. When information is not available to make an interface selection, the connection manager will query the user to choose between available choices.
これは、携帯電話のオペレーティングシステムは、アプリケーションまたはユーザ入力に基づいて、ネットワーク・インターフェース選択を行う集中接続マネージャを使用するのが一般的です。しかし、接続マネージャは、通常、インタフェースの選択に問題を制限し、[RFC6418]で定義されるように、プロビジョニングドメインの選択に対応していません。接続マネージャによって使用される情報は、アプリケーションにプログラムまたはハンドセット全体にプロビジョニングすることができます。情報は、インターフェイスの選択を行うことができない場合は、接続マネージャは、利用可能な選択肢の間で選択するようにユーザーを照会します。
Routing tables are not typically used for network interface selection when a connection manager is in use, as the criteria for network selection is not strictly IP-based but is also dependent on other properties of the interface (cost, type, etc.). Furthermore, multiple overlapping private IPv4 address spaces are often exposed to a multiple-interface host, making it difficult to make interface selection decisions based on prefix matching.
接続マネージャを使用している場合、ネットワーク選択のための基準は、厳密IPベースではなく、インターフェースの他の特性（コスト、タイプ、等）に依存しているように、ルーティングテーブルは、典型的には、ネットワーク・インターフェース選択のために使用されていません。さらに、複数の重複プライベートIPv4アドレス空間は、多くの場合、それが困難な接頭辞マッチングに基づくインタフェース選択決定を行うために作り、複数のインターフェイスホストにさらされています。
In mobile handsets, applications are often involved in choosing what interface and related configuration information should be used. In some cases, the application selects the interface directly, and in other cases, the application provides more abstract information to a connection manager that makes the final interface choice.
携帯電話では、アプリケーションは、多くの場合、インターフェイスおよび関連する構成情報を使用すべきかの選択に関与しています。いくつかのケースでは、アプリケーションは直接インタフェースを選択し、それ以外の場合に、アプリケーションは、最終的なインターフェースの選択を行う接続マネージャーにより抽象的な情報を提供します。
In most desktop operating systems, multiple-interface problems are dealt with in the stack and related components, based on system-level configuration information, without the benefit of input from applications or users. These solutions tend to map well to the problems listed in the problem statement:
ほとんどのデスクトップオペレーティングシステムでは、複数のインタフェースの問題は、アプリケーションまたはユーザからの入力の恩恵なしに、システム・レベルの構成情報に基づいて、スタックおよび関連コンポーネントで取り扱われます。これらのソリューションは、問題文で記載されている問題にうまくマッピングする傾向があります：
o DNS resolution issues
O DNS解決の問題
o Routing
Oルーティング
o Address selection policy
Oアドレス選択ポリシー
The configuration information for desktop systems comes from one of the following sources: DHCP, router advertisements, proprietary configuration systems, or manual configuration. While these systems universally accept IP address assignment on a per-interface basis, they differ in what set of information can be assigned on a per-interface basis and what can be configured only on a per-system basis.
DHCP、ルータ広告、独自のコンフィギュレーション・システム、または手動設定：デスクトップシステムの構成情報は、次のいずれかのソースから来ています。これらのシステムは普遍的インターフェイスごとにIPアドレスの割り当てを受け入れるが、それらは、インターフェイスごとに割り当てることができ、どのようなだけシステムごとに構成することができる情報のどのセットが異なります。
When choosing between multiple sets of information provided, these systems will typically give preference to information received on the "primary" interface. The mechanism for designating the "primary" interface differs by system.
提供される情報の複数のセット間で選択するときに、これらのシステムは、典型的には、「一次」インターフェース上で受信された情報に優先順位を与えます。 「一次」インターフェースを指定するためのメカニズムは、システムによって異なります。
There is very little commonality in how desktop operating systems handle multiple sets of configuration information, with notable variations between different versions of the same operating system and/or within different software packages built for the same operating system. Although these systems differ widely, it is not clear that any of them provide a completely satisfactory user experience in multiple-interface environments.
デスクトップオペレーティングシステムおよび/または同じオペレーティングシステム用に構築された別のソフトウェアパッケージ内の同じオペレーティングシステムの異なるバージョン間で顕著なバリエーションを持つ構成情報の複数のセットを、どのように処理するかにはほとんど共通点があります。これらのシステムは大きく異なりますが、それらのいずれかが、複数のインターフェイス環境では完全に満足できるユーザーエクスペリエンスを提供することは明らかではありません。
The following sections discuss some of the solutions used in each of the areas raised in the MIF problem statement.
次のセクションでは、MIFの問題文で盛り上がった領域のそれぞれに使用される溶液のいくつかを議論します。
There is very little commonality in how desktop operating systems handle the DNS server list. Some systems support per-interface DNS server lists, while others only support a single system-wide list.
デスクトップオペレーティングシステムは、DNSサーバのリストを処理する方法にはほとんど共通点があります。他の人は、単一のシステム全体のリストをサポートしながら、いくつかのシステムでは、インターフェースごとのDNSサーバーのリストをサポート。
On hosts with per-interface DNS server lists, different mechanisms are used to determine which DNS server is contacted for a given query. In most cases, the first DNS server listed on the "primary" interface is queried first, with back off to other servers if an answer is not received.
インターフェイス単位のDNSサーバのリストを持つホストに、異なるメカニズムが、所与のクエリのために接触させるDNSサーバを決定するために使用されます。ほとんどの場合、「プライマリ」のインターフェイスに記載されている最初のDNSサーバは、答えが受信されない場合は、他のサーバーにバックオフして、最初に照会されます。
Systems that support a single system-wide list differ in how they select which DNS server to use in cases where they receive more than one DNS server list to configure (e.g., from DHCP on multiple interfaces). Some accept the information received on the "primary" interface, while others use either the first or last set DNS server list configured.
単一のシステム全体のリストをサポートするシステムは、彼らが（複数のインターフェイス上でDHCPから、例えば）を設定するために、1つのDNSサーバのリストを超えて受け取る場合に使用するDNSサーバ選択方法が異なります。他の人が最初または最後に設定されたDNSサーバのリストに構成を使用しながら、いくつかは、「プライマリ」のインターフェイス上で受信した情報を受け入れます。
Routing information is also handled differently on different desktop operating systems. While all systems maintain some sort of routing cache, to handle redirects and/or statically configured routes, most packets are routed based on configured default gateway information.
ルーティング情報は、異なるデスクトップオペレーティングシステムで異なる方法で処理されます。すべてのシステムがリダイレクトおよび/または静的に設定されたルートを処理するために、ルーティングキャッシュのいくつかの並べ替えを維持しながら、ほとんどのパケットは、設定されたデフォルトゲートウェイの情報に基づいてルーティングされます。
Some systems do allow the configuration of different default router lists for different interfaces. These systems will always choose the default gateway on the interface with the lowest routing metric, with different behavior when two or more interfaces have the same routing metric.
いくつかのシステムは、異なるインターフェイスごとに異なるデフォルトルータリストを設定できません。二つ以上のインターフェースが同一のルーティング・メトリックを有する場合、これらのシステムは、常に異なる動作と、最低のルーティングメトリックとのインタフェース上のデフォルトゲートウェイを選択します。
Most systems do not allow the configuration of more than one default router list, choosing instead to use the first or last default router list configured and/or the router list configured on the "primary" interface.
ほとんどのシステムは、最初または最後のデフォルトルータのリストが設定され、および/または「プライマリ」インターフェイスに設定されているルータリストを使用する代わりに選択すると、複数のデフォルトルータリストの設定を許可していません。
There is somewhat more commonality in how desktop hosts handle address selection. Applications typically provide the destination address for an outgoing packet, and the IP stack is responsible for picking the source address.
デスクトップのホストがアドレス選択を処理する方法で幾分共通性があります。アプリケーションは通常、発信パケットの宛先アドレスを提供し、IPスタックは、送信元アドレスを選ぶための責任があります。
IPv6 specifies a specific source address selection mechanism in [RFC3484], and several systems implement this mechanism with similar support for IPv4. However, many systems do not provide any mechanism to update this default policy, and there is no standard way to do so.
IPv6は[RFC3484]で特定の送信元アドレス選択メカニズムを指定し、いくつかのシステムは、IPv4の同様の支持体と、このメカニズムを実装します。しかし、多くのシステムでは、このデフォルトのポリシーを更新するための任意のメカニズムを提供しませんし、そうするための標準的な方法はありません。
In some cases, the routing decision (including which interface to use) is made before source address selection is performed, and a source address is chosen from the outbound interface. In other cases, source address selection is performed before, or independently from, outbound interface selection.
ソースアドレス選択が行われる前に、いくつかのケースでは、ルーティング決定（使用するインターフェイスを含む）が行われ、送信元アドレスは、発信インターフェイスから選択されます。他の場合には、送信元アドレスの選択は前に、または独立して発信インタフェース選択、から行われます。
The material presented in this section is derived from contributions from people familiar with the operating systems described (see Section 6 a list of these individuals). The authors and the IETF take no position about the operating systems described and understand that other operating systems also exist. Furthermore, it should be understood that Section 3 describes particular behaviors that were believed to be current at the time this document was written: earlier and later versions of the operating systems described may exhibit different behaviors. Please refer to the References section for pointers to original documentation, including further details.
このセクションに提示された資料は、（これらの個人のセクション6リストを参照してください）説明オペレーティング・システムに精通している人からの貢献に由来しています。著者とIETFは、説明のオペレーティングシステムについての位置を取らず、他のオペレーティングシステムも存在することを理解しています。説明オペレーティングシステムの以前および以降のバージョンでは異なる挙動を示す可能性があります。また、第3節は、この文書が書かれた時点での電流であると考えられた特定の行動を記述することを理解すべきです。さらに詳細を含め、元のドキュメントへのポインタについては、参考文献のセクションを参照してください。
Cellular devices typically run a variety of applications in parallel, each with different requirements for IP connectivity. A typical scenario is shown in Figure 1, where a cellular device is utilizing Wireless Local Area Network (WLAN) access for web browsing and General Packet Radio Service (GPRS) access for transferring multimedia messages (MMS). Another typical scenario would be a real-time Voice over IP (VoIP) session over one network interface in parallel with best-effort web browsing on another network interface. Yet another typical scenario would be global Internet access through one network interface and local (e.g., corporate VPN) network access through another.
携帯デバイスは、通常、IP接続のためのさまざまな要件をそれぞれ、並行して様々なアプリケーションを実行します。典型的なシナリオは、携帯デバイスは、Webブラウジングやマルチメディアメッセージ（MMS）を転送するための汎用パケット無線サービス（GPRS）アクセスのためのワイヤレスローカルエリアネットワーク（WLAN）アクセスを利用している。図1に示されています。もう一つの典型的なシナリオは、別のネットワークインターフェイス上のベストエフォート型のWebブラウジングと並行して、一つのネットワークインタフェースを介してリアルタイムボイスオーバーIP（VoIP）のセッションになります。さらに別の典型的なシナリオは、一つのネットワークインターフェースと他介してローカル（例えば、企業VPN）のネットワークアクセスを介してグローバルインターネットアクセスであろう。
Web server MMS Gateway
| |
-+--Internet---- ----Operator network--+-
| |
+-------+ +-------+
|WLAN AP| | GGSN |
+-------+ +-------+
| +--------+ |
+--------|Cellular|--------+
|device |
+--------+
A Cellular Device with Two Network Interfaces
2つのネットワークインタフェースを備えた携帯機器
Figure 1
図1
Different network access technologies require different settings. For example, WLAN requires the Service Set Identifier (SSID), and the GPRS network requires the Access Point Name (APN) of the Gateway GPRS Support Node (GGSN), among other parameters. It is common that different accesses lead to different destination networks (e.g., to Internet, intranet, cellular network services, etc.).
異なるネットワークアクセス技術は、異なる設定が必要です。例えば、WLANは、サービスセット識別子（SSID）を必要とし、GPRSネットワークは、他のパラメータの中で、ゲートウェイGPRSサポートノード（GGSN）のアクセスポイント名（APN）が必要です。異なるアクセスが（インターネット、イントラネット、セルラネットワークサービス、等に、例えば）異なる宛先ネットワークにつながることが一般的です。
S60 is a software platform for mobile devices running on the Symbian operating system (OS). S60 uses the concept of an Internet Access Point (IAP) [S60] that contains all information required for opening a network connection using a specific access technology. A device may have several IAPs configured for different network technologies and settings (multiple WLAN SSIDs, GPRS APNs, dial-up numbers, and so forth). There may also be 'virtual' IAPs that define parameters needed for tunnel establishment (e.g., for VPN).
S60は、Symbianオペレーティングシステム（OS）上で動作しているモバイルデバイス用のソフトウェアプラットフォームです。 S60は、特定のアクセス技術を使用してネットワーク接続を開くために必要なすべての情報が含まれているインターネットアクセスポイント（IAP）[S60]の概念を使用しています。デバイスは、異なるネットワーク技術と設定（複数のWLANのSSID、GPRSのAPN、ダイヤルアップ番号、等）のために設定いくつかのIAPを有していてもよいです。また、（VPNのために、例えば）トンネル確立のために必要なパラメータを定義する「仮想」のIAPがあってもよいです。
For each application, a correct IAP needs to be selected at the point when the application requires network connectivity. This is essential, as the wrong IAP may not be able to support the application or reach the desired destination. For example, an MMS application must use the correct IAP in order to reach the MMS Gateway, which typically is not accessible from the public Internet. As another example, an application might need to use the IAP associated with its corporate VPN in order to reach internal corporate servers. Binding applications to IAPs avoids several problems, such as choosing the correct DNS server in the presence of split DNS (as an application will use the DNS server list from its bound IAP) and overlapping private IPv4 address spaces used for different interfaces (as each application will use the default routes from its bound IAP).
各アプリケーションのために、正しいIAPは、アプリケーションがネットワーク接続を必要とする点で選択される必要があります。間違ったIAPアプリケーションをサポートしたり、所望の目的地に到達することができないかもしれないので、これは、必要不可欠です。例えば、MMSアプリケーションは、一般的に、公共のインターネットからアクセスすることはできませんMMSゲートウェイに到達するために、正しいIAPを使用する必要があります。別の例として、アプリケーションは、社内のサーバーに到達するために、その企業のVPNに関連付けられたIAPを使用する必要があります。 IAPへのアプリケーションの結合は、各アプリケーションのようなスプリットDNSの存在下で正しいDNSサーバーを選択するようないくつかの問題、（アプリケーションとしてその結合IAPからDNSサーバーのリストを使用する）と異なるインターフェースに使用される重複プライベートIPv4アドレス空間を（回避します）その結合IAPからデフォルトルートを使用します。
If multiple applications utilize the same IAP, the underlying network connection can typically be shared. This is often the case when multiple Internet-using applications are running in parallel.
複数のアプリケーションが同一のIAPを利用する場合、基本的なネットワーク接続は、典型的に共有することができます。これは、多くの場合、複数のインターネット使用してアプリケーションを並列に実行されている場合です。
The IAP for an application can be selected in multiple ways:
アプリケーションのためのIAPは、複数の方法で選択することができます。
o Statically: for example, from a configuration interface, via client provisioning/device management system, or at build-time.
O静的：例えば、コンフィギュレーション・インタフェースから、クライアントプロビジョニング/デバイス管理システムを介して、またはビルド時。
o Manually by the user: for example, each time an application starts, the user may be asked to select the IAP to use. This may be needed, for example, if a user sometimes wishes to access his corporate intranet and other times would prefer to access the Internet directly.
Oを手動でユーザーによって：たとえば、アプリケーションが起動するたびに、ユーザーが使用するIAPを選択するよう求められることがあります。ユーザーは時々彼の企業イントラネットにアクセスしたいと他の回は、直接インターネットにアクセスすることを好む場合、これは、例えば、必要になる場合があります。
o Automatically by the system: after the destination network has been selected statically or dynamically.
O自動システムによって：宛先ネットワーク後に静的または動的に選択されています。
The static approach is fine for certain applications, like MMS, for which configuration can be provisioned by the network operator and does not change often. Manual selection works but may be seen as troublesome by the user. An automatic selection mechanism needs to have some way of knowing which destination network the user, or an application, is trying access.
静的なアプローチは、コンフィギュレーションは、ネットワークオペレータによってプロビジョニングすることができ、頻繁に変化しないため、MMS、などの特定の用途のための罰金です。手動選択は動作しますが、ユーザーが面倒として見ることができます。自動選択メカニズムは、ユーザー、またはアプリケーションは、アクセスをしようとしている宛先ネットワーク知る何らかの方法を持っている必要があります。
S60 3rd Edition, Feature Pack 2 introduces the concept of Service Network Access Points (SNAPs) that group together IAPs that lead to the same destination. This enables static or manual selection of the destination network for an application and leaves the problem of selecting the best of the available IAPs within a SNAP to the operating system.
一緒S60第3版、機能パック2サービスネットワークアクセスポイント（のSNAP）の概念を導入し、そのグループ同じ宛先につながるのIAP。これは、アプリケーションの接続先ネットワークの静的または手動選択を可能にし、オペレーティングシステムへのSNAP内で使用可能IAPの最善の選択の問題を残しています。
When SNAPs are used, the operating system can notify applications when a preferred IAP, leading to the same destination, becomes available (for example, when a user comes within range of his home WLAN access point) or when the currently used IAP is no longer available. If so, applications have to reconnect via another IAP (for example, when a user goes out of range of his home WLAN and must move to the cellular network).
SNAPが使用される場合、好ましいIAPは、同じ宛先に至る、利用可能になったとき、オペレーティングシステムはアプリケーションに通知することができ、または現在使用IAPがもはやである場合（ユーザが自分のホームWLANアクセスポイントの範囲内に入る例えば、用）利用可能。その場合、アプリケーションは、（ユーザーが自宅の無線LANの範囲の外に出ると、セルラーネットワークに移動する必要があります例えば、）別のIAPを経由して再接続する必要があります。
S60 3.2 does not support RFC 3484 for source address selection mechanisms. Applications are tightly bound to the network interface selected for them or by them. For example, an application may be connected to an IPv6 3G connection, IPv4 3G connection, WLAN connection, or VPN connection. The application can change between the connections but uses only one at a time. If the interface happens to be dual-stack, then IPv4 is preferred over IPv6.
S60 3.2は、ソースアドレス選択メカニズムのためのRFC 3484をサポートしていません。アプリケーションは、しっかりと彼らのためにまたはそれらによって選択されたネットワークインタフェースにバインドされています。例えば、アプリケーションは、IPv6 3G接続、IPv4の3G接続、WLAN接続、またはVPN接続に接続することができます。アプリケーションが接続間で変化するが、一度に1つを使用することができます。インターフェイスは、デュアルスタックであることを起こる場合、IPv4がIPv6で好ましいです。
DNS configuration is per-interface; an application bound to an interface will always use the DNS settings for that interface. Hence, the device itself remembers these pieces of information for each interface separately.
DNS構成ごとのインタフェースです。インターフェイスにバインドされたアプリケーションは、常にそのインターフェイスのDNS設定を使用します。したがって、装置自体が別々に各インターフェイスのためこれらの情報を記憶しています。
S60 3.2 manages with totally overlapping addresses spaces. Each interface can even have the same IPv4 address configured on it without issues because interfaces are kept totally separate from each other. This implies that interface selection has to be done at the application layer, as from the network-layer point of view, a device is not multihomed in the IP-sense.
S60 3.2は完全に重複アドレススペースで管理します。インターフェイスが互いから完全に分離して保持されているので、各インタフェースも問題なく、その上に構成された同じIPv4アドレスを持つことができます。これは、インタフェースの選択は、デバイスがIP-意味でマルチホームされていないビューのネットワーク層の点からように、アプリケーション層で行われなければならないことを意味します。
Please see the S60 source documentation for more details and screenshots [S60].
詳細とスクリーンショット[S60]のためのS60ソースのドキュメントを参照してください。
Microsoft Windows Mobile leverages a connection manager [WINDOWSMOBILE] to handle multiple network connections. This architecture centralizes and automates network connection establishment and management and makes it possible to automatically select a connection, to dial-in automatically or by user initiation, and to optimize connection and shared resource usage. The connection manager periodically re-evaluates the validity of the connection selection. The connection manager uses various attributes such as cost, security, bandwidth, error rate, and latency in its decision making.
マイクロソフトのWindows Mobileは、複数のネットワーク接続を処理するために、接続マネージャ[WINDOWSMOBILE]を利用しています。このアーキテクチャは、集中化と自動化、ネットワーク接続確立および管理を、自動的にまたはユーザ開始によって、ダイヤルインするために、接続と共有リソースの使用を最適化するために、自動的に接続を選択することができます。接続マネージャは、定期的に接続選択の妥当性を再評価します。接続マネージャは、その意思決定におけるコスト、セキュリティ、帯域幅、エラー率、および待ち時間などのさまざまな属性を使用しています。
The connection manager selects the best possible connection for the application based on the destination network the application wishes to reach. The selection is made between available physical and virtual connections (e.g., VPN, GPRS, WLAN, and wired Ethernet) that are known to provide connectivity to the destination network, and the selection is based on the costs associated with each connection. Different applications are bundled to use the same network connection when possible, but in conflict situations when a connection cannot be shared, higher-priority applications take precedence, and the lower-priority applications lose connectivity until the conflict situation clears.
接続マネージャは、アプリケーションが到達したい宛先ネットワークに基づいてアプリケーションのための最高の可能な接続を選択します。選択は、宛先ネットワークへの接続を提供することが知られている使用可能な物理および仮想コネクション（例えば、VPN、GPRS、WLAN、有線イーサネット（登録商標））との間に形成されており、選択は、各接続に関連するコストに基づいています。異なるアプリケーションが可能な場合は、同じネットワーク接続を使用するためにバンドルされているが、競合状況での接続が優先度の高いアプリケーションが優先され、競合状況が解消されるまで、優先度の低いアプリケーションは、接続が失われる、共有することができない場合。
During operation, the connection manager opens new connections as needed and also disconnects unused or idle connections.
動作時には、接続マネージャは、必要に応じて新しい接続を開き、また、未使用またはアイドル状態の接続を切断します。
To optimize resource use, such as battery power and bandwidth, the connection manager enables applications to synchronize network connection usage by allowing applications to register their requirements for periodic connectivity. An application is notified when a suitable connection becomes available for its use.
このようなバッテリ電力および帯域幅などのリソースの使用を最適化するために、接続マネージャは、アプリケーションは、アプリケーションが定期的接続のための要件を登録できるようにすることで、ネットワーク接続の使用を同期させることが可能となります。アプリケーションは、適切な接続が使用可能になったときに通知されます。
In comparison to Windows Mobile connection management, Windows Phone 7 updates the routing functionality in the case where the terminal can be attached simultaneously to several interfaces. Windows Phone 7 selects the first hop corresponding to the interface that has a lower metric. When there are multiple interfaces, the applications system will, by default, choose from an ordered list of available interfaces. The default connection policy will prefer wired over wireless and WLAN over cellular. Hence, if an application wants to use cellular 3G as the active interface when WLAN is available, the application needs to override the default connection mapping policy. An application-specific mapping policy can be set via a Microsoft API or provisioned by the Mobile Operator. The application, in compliance with the security model, can request connection type by interface (WLAN, cellular), by minimum interface speed (x kbit/s, y Mbit/s), or by name (Access Point Name).
Windows Mobileの接続管理と比較して、Windowsの携帯電話7は、端末が複数のインターフェイスに同時に結合することができる場合にはルーティング機能を更新します。 Windowsの携帯電話7は、より低いメトリックを持つインタフェースに対応する最初のホップを選択します。複数のインターフェースがある場合、アプリケーション・システムは、デフォルトで、使用可能なインターフェイスの順序付きリストから選択します。デフォルトの接続ポリシーは、携帯超える無線およびWLAN上で有線好むでしょう。したがって、アプリケーションは、WLANが利用可能な場合、アプリケーションはデフォルトの接続マッピングポリシーを上書きする必要がアクティブインターフェイスとして携帯3Gを使用したい場合。アプリケーション固有のマッピングポリシーは、MicrosoftのAPIを介して設定するか、モバイルオペレータによってプロビジョニングすることができます。セキュリティモデルに準拠したアプリケーションは、インターフェース（WLAN、セルラ）によって、最小のインターフェイス速度（Xキロビット/秒、Yメガビット/秒）によって、または名前（アクセスポイント名）によって接続タイプを要求することができます。
In dual-stack systems, Windows Mobile and Windows Phone 7 implement address selection rules per [WNDS-RFC3484]. An administrator can configure a policy table that can override the default behavior of the selection algorithms. Note that the policy table specifies precedence values and preferred source prefixes for destination prefixes (see [RFC3484], Section 2.1 for details). If the system has not been configured, then the default policy table specified in [RFC3484] is used.
デュアルスタックシステムでは、Windows MobileのとWindows Phone 7のは、[WNDS-RFC3484]あたりのアドレス選択ルールを実装します。管理者は、選択アルゴリズムのデフォルト動作をオーバーライドすることができ、ポリシーテーブルを設定することができます。ポリシーテーブルは、宛先プレフィックス（[RFC3484]を参照し、詳細についてはセクション2.1）のための優先順位値および好ましいソースプレフィックスを指定することに留意されたいです。システムが構成されていない場合は、[RFC3484]で指定されたデフォルト・ポリシー・テーブルが使用されます。
Depending on the network configuration, applications in Research In Motion (RIM) BlackBerry devices [BLACKBERRY] can use direct TCP/IP connectivity or different application proxies to establish connections over the wireless network. For instance, some wireless service providers provide an Internet gateway to offer direct TCP/IP connectivity to the Internet while some others can provide a Wireless Application Protocol (WAP) gateway that allows HTTP connections to occur over WAP. It is also possible to use the BlackBerry Enterprise Server [BLACKBERRY] as a network gateway. The BlackBerry Enterprise Server provides an HTTP and TCP/IP proxy service to allow the application to use it as a secure gateway for managing HTTP and TCP/IP connections to the intranet or the Internet. An application connecting to the Internet can use either the BlackBerry Internet Service or the Internet gateway of the wireless server provider or direct Internet connectivity over WLAN to manage connections. The problem of gateway selection is supposed to be managed independently by each application. For instance, an application can be designed to always use the default Internet gateway, while another application can be designed to use a preferred proxy when available.
ネットワーク構成によっては、Research In Motionは中のアプリケーション（RIM）のBlackBerryデバイス[ブラックベリー]は、無線ネットワークを介して接続を確立するために、直接TCP / IP接続または別のアプリケーションプロキシを使用することができます。例えば、いくつかの無線サービスプロバイダは、いくつか他の人がHTTP接続はWAP上で発生することを可能にするワイヤレスアプリケーションプロトコル（WAP）ゲートウェイを提供することができるが、インターネットに直接TCP / IP接続を提供するためにインターネットゲートウェイを提供します。ネットワークゲートウェイとしてのBlackBerry Enterprise Serverの[BLACKBERRY]を使用することも可能です。 BlackBerry Enterprise Serverは、アプリケーションがイントラネットやインターネットへのHTTPおよびTCP / IP接続を管理するためのセキュアゲートウェイとしてそれを使用できるようにするHTTPおよびTCP / IPプロキシサービスを提供しています。インターネットに接続するアプリケーションは、接続を管理する無線LAN経由でBlackBerry Internet Serviceまたはワイヤレスサーバープロバイダやインターネットに直接接続のインターネットゲートウェイのいずれかを使用することができます。ゲートウェイ選択の問題は、各アプリケーションが独立して管理することになっています。他のアプリケーションが利用可能な場合、好ましいプロキシを使用するように設計することができるが、例えば、アプリケーションは、常にデフォルトのインターネットゲートウェイを使用するように設計することができます。
A BlackBerry device [BLACKBERRY] can be attached to multiple networks simultaneously (wireless/wired). In this case, multiple network interfaces can be associated to a single IP stack or multiple IP stacks. The device, or the application, can select the network interface to be used in various ways. For instance, the device can always map the applications to the default network interface (or the default access network). When multiple IP stacks are associated to multiple interfaces, the application can select the source address corresponding to the preferred network interface. Per-interface IP stacks also allow to manage overlapping address spaces. When multiple network interfaces are aggregated into a single IP stack, the device associates each application to the more appropriate network interface. The selection can be based on cost, type of service (ToS), and/or user preference.
BlackBerryデバイス[BLACKBERRYは、（有線/無線）同時に複数のネットワークに接続することができます。この場合には、複数のネットワークインターフェイスは、単一のIPスタックまたは複数のIPスタックに関連付けることができます。デバイス、またはアプリケーションは、様々な方法で使用するネットワーク・インターフェースを選択することができます。例えば、デバイスは常にデフォルトのネットワーク・インターフェース（またはデフォルトのアクセス・ネットワーク）にアプリケーションをマッピングすることができます。複数のIPスタックが複数のインターフェイスに関連付けられている場合、アプリケーションは、好ましいネットワークインターフェースに対応するソースアドレスを選択することができます。インターフェイス単位のIPスタックは、アドレススペースの重複管理することができます。複数のネットワークインタフェースが、単一のIPスタックに集約されている場合、デバイスは、より適切なネットワークインタフェースに各アプリケーションを関連付けます。選択は、コスト、サービスのタイプ（TOS）、および/またはユーザの好みに基づくことができます。
The BlackBerry uses per-interface DNS configuration; applications bound to a specific interface will use the DNS settings for that interface.
ブラックベリーは、インターフェースごとのDNS設定を使用します。特定のインターフェイスにバインドされたアプリケーションは、そのインターフェイスのDNS設定を使用します。
Android is based on a Linux kernel and, in many situations, behaves like a Linux device as described in Section 3.2.2. Per Linux, Android can manage multiple routing tables and relies on policy-based routing associated with packet-filtering capabilities (see Section 3.2.2.1 for details). Such a framework can be used to solve complex routing issue brought by multiple interfaces terminals, e.g., address space overlapping.
アンドロイドは、Linuxカーネルに基づいており、3.2.2項で説明したように、多くの状況では、Linuxデバイスのように動作しています。 Linuxのあたりに、Androidは複数のルーティングテーブルを管理することができ、パケットフィルタリング機能（詳細はセクション3.2.2.1を参照）に関連付けられたポリシーベースルーティングに依存しています。そのようなフレームワークは、複数のインタフェース端子、例えば、アドレス空間の重複によってもたらされる複雑なルーティングの問題を解決するために使用することができます。
For incoming packets, Android implements the weak host model [RFC1122] on both IPv4 and IPv6. However, Android can also be configured to support the strong host model.
着信パケットは、Androidは、IPv4とIPv6の両方に弱いホストモデル[RFC1122]を実装します。しかし、Androidはまた、強力なホストモデルをサポートするように設定することができます。
Regarding DNS configuration, Android does not list the DNS servers in the file /etc/resolv.conf, used by Linux. However, per Linux, DNS configuration is node-scoped, even if DNS configuration can rely on the DHCP client. For instance, the udhcp client [UDHCP], which is also available for Linux, can be used on Android. Each time new configuration data is received by the host from a DHCP server, regardless of which interface it is received on, the DHCP client rewrites the global configuration data with the most recent information received.
DNSの設定については、Androidのは、Linuxで使用される/etc/resolv.confファイル内のDNSサーバを、一覧表示されません。しかし、Linuxのあたりに、DNSの設定は、DNSの設定はDHCPクライアントに依存することができたとしても、ノード・スコープです。例えば、Linux用にも使用可能ですudhcpクライアント[UDHCP]は、Android上で使用することができます。たびに新しいコンフィギュレーション・データは関係なく、それが受信したインタフェースの、DHCPサーバからホストによって受信され、DHCPクライアントが受信した最新の情報とグローバル・コンフィギュレーション・データを書き換えます。
Actually, the main difference between Linux and Android is on the address selection mechanism. Android versions prior to 2.2 simply prefer IPv6 connectivity over IPv4. However, it should be noted that, at the time of this writing, IPv6 is available only on WiFi and virtual interfaces but not on the cellular interface (without IPv6 in IPv4 encapsulation). Android 2.2 has been updated with [ANDROID-RFC3484], which implements some of the address selection rules defined in [RFC3484]. All [RFC3484] rules are supported, except rule 3 (avoid deprecated addresses), rule 4 (prefer home addresses), and rule 7 (prefer native transport). Also, rule 9 (use longest matching prefix) has been modified so it does not sort IPv4 addresses.
実際には、LinuxとAndroidの間の主な違いは、アドレス選択メカニズムです。前2.2へのAndroidのバージョンは、単純に、IPv4からIPv6接続を好みます。しかし、これを書いている時点で、IPv6が唯一のWi-Fi、仮想インタフェース上ではなく、（IPv6のIPv4のカプセル化せず）、セルラインタフェース上で利用可能であることに留意すべきです。アンドロイド2.2は、[RFC3484]で定義されたアドレス選択ルールの一部を実現[ANDROID-RFC3484]で更新されています。全ての[RFC3484]のルールは、ルール3（非推奨アドレスを避けるため）、規則4（ホームアドレスを好む）、およびルール7（ネイティブ輸送を好む）を除いて、サポートされています。それはIPv4アドレスをソートしていないので、また、ルール9は、（最長一致接頭辞を使用）に変更されました。
The Android reference documentation describes the android.net package [ANDROID] and the ConnectivityManager class that applications can use to request the first hop to a specified destination address via a specified network interface (Third Generation Partnership Project (3GPP) or WLAN). Applications also ask the connection manager for permission to start using a network feature. The connection manager monitors changes in network connectivity and attempts to failover to another network if connectivity to an active network is lost. When there are changes in network connectivity, applications are notified. Applications are also able to ask for information about all network interfaces, including their availability, type, and other information.
Androidの参照資料はandroid.netパッケージ[ANDROID]とアプリケーションが指定されたネットワークインターフェース（第3世代パートナーシッププロジェクト（3GPP）またはWLAN）を介して指定された宛先アドレスへの最初のホップを要求するために使用できるConnectivityManagerクラスを記載しています。また、アプリケーションは、ネットワーク機能の使用を開始する許可のための接続マネージャをお願いします。接続マネージャは、ネットワーク接続の変更を監視し、アクティブなネットワークへの接続が失われた場合、別のネットワークにフェイルオーバーすることを試みます。ネットワーク接続の変更がある場合、アプリケーションが通知されます。また、アプリケーションは、可用性、タイプ、およびその他の情報を含め、すべてのネットワークインターフェイスに関する情報を求めることができます。
This section describes how multiple-interface support is handled by Advanced Mobile Station Software (AMSS) that comes with Brew OS for all Qualcomm chipsets (e.g., Mobile Station Modem (MSM), Snapdragon, etc.). AMSS is a low-level connectivity platform, on top of which manufacturers can build to provide the necessary connectivity to applications. The interaction model between AMSS, the operating system, and the applications is not unique and depends on the design chosen by the manufacturer. The Mobile OS can let an application invoke the AMSS directly (via API) or provide its own connection manager that will request connectivity to the AMSS based on applications needs. The interaction between the OS connection manager and the applications is OS dependent.
このセクションでは、複数のインターフェイスのサポートがすべてのクアルコムのチップセットのために醸造OSに付属している高度なモバイルステーションソフトウェア（AMSS）によって処理される方法を説明します（例えば、移動局モデム（MSM）、キンギョソウ、など）。 AMSSは、メーカーがアプリケーションに必要な接続性を提供するために構築することができたの上に、低レベルのコネクティビティ・プラットフォームです。 AMSS、オペレーティングシステム、およびアプリケーション間の相互作用モデルは、固有のものではなく、メーカーによって選ばれたデザインに依存します。モバイルOSは、アプリケーションが（API経由で）直接AMSSを呼び出してみましょうか、アプリケーションのニーズに基づいてAMSSへの接続を要求する独自の接続マネージャを提供することができます。 OS接続マネージャとアプリケーション間の相互作用はOSに依存します。
AMSS supports a concept of netpolicy that allows each application to specify the type of network connectivity desired. The netpolicy contains parameters such as access technology, IP version type, and network profile. Access technology could be a specific technology type such as CDMA or WLAN or could be a group of technologies, such as ANY_Cellular or ANY_Wireless. IP version could be one of IPv4, IPv6, or Default. The network profile identifies a type of network domain or service within a certain network technology, such as 3GPP APN or Mobile IP Home Agent. It also specifies all the mandatory parameters required to connect to the domain such authentication credentials and other optional parameters such as Quality of Service (QoS) attributes. Network profile is technology specific, and the set of parameters contained in the profile could vary for different technologies.
AMSSは、各アプリケーションは、所望のネットワーク接続のタイプを指定することができnetpolicyの概念をサポートします。 netpolicyは、このようなアクセス技術、IPバージョンの種類、およびネットワークプロファイルなどのパラメータが含まれています。アクセス技術は、CDMAまたはWLANなどの特定の技術タイプである可能性があり、あるいはANY_CellularやANY_Wirelessなどの技術、のグループである可能性があります。 IPのバージョンは、IPv4、IPv6の、またはデフォルトのいずれかになります。ネットワークプロファイルは、3GPP APNやモバイルIPホームエージェントとして、特定のネットワーク技術内のネットワークドメインまたはサービスの種類を識別します。また、ドメインなどの認証資格情報と、そのようなサービスの品質（QoS）などの他のオプションパラメータに接続するために必要なすべての必須パラメータを指定する属性。ネットワークプロファイルは、技術固有のものであり、プロファイルに含まれるパラメータのセットは、異なる技術のために変化させることができます。
Two models of network usage are supported:
ネットワークの使用率の2つのモデルがサポートされています。
o Applications requiring network connectivity specify an appropriate netpolicy in order to select the desired network. The netpolicy may match one or more network interfaces. The AMSS system selection module selects the best interface out of the ones that match the netpolicy based on various criteria such as cost, speed, or other provisioned rules. The application explicitly starts the selected network interface and, as a result, the application also gets bound to the corresponding network interface. All outbound packets from this application are always routed over this bound interface using the source address of the interface.
ネットワーク接続を必要とOアプリケーションは、所望のネットワークを選択するために適切なnetpolicyを指定します。 netpolicyは、1つまたは複数のネットワークインタフェースを一致させることができます。 AMSSシステム選択モジュールは、コスト、速度、または他のプロビジョニングのルールのような様々な基準に基づいてnetpolicyと一致するもののうち、最高のインタフェースを選択します。アプリケーションが明示的に結果として、アプリケーションは、対応するネットワーク・インターフェースにバインドされます、選択されたネットワーク・インターフェースを開始し。このアプリケーションからのすべてのアウトバウンドパケットは、常にインターフェイスの送信元アドレスを使用して、このバウンドインターフェイスの上に配線されています。
o Applications may rely on a separate connection manager to control (e.g., start/stop) the network interface. In this model, applications are not necessarily bound to any one interface. All outbound packets from such applications are routed on one of the interfaces that match its netpolicy. The routing decision is made individually for each packet and selects the best interface based on the criteria described above and the destination address. Source address is always assigned to the interface used to transmit the packet.
Oアプリケーション（例えば、開始/停止）を制御するために個別の接続マネージャのネットワークインタフェースを頼ることができます。このモデルでは、アプリケーションは必ずいずれかのインターフェイスにバインドされていません。そのようなアプリケーションからのすべてのアウトバウンドパケットは、そのnetpolicyに一致するインターフェイスのいずれかにルーティングされます。ルーティング決定は、各パケットごとに個別に作製し、上記基準と宛先アドレスに基づいて、最適なインタフェースを選択します。送信元アドレスは、常にパケットを送信するために使用されるインタフェースに割り当てられています。
All of the routing/interface selection decisions are based on the netpolicy and not just on the destination address to avoid the issue of overlapping private IPv4 addresses. This also allows multiple interfaces to be configured with the same IP address, for example, to handle certain tunneling scenarios. Applications that do not specify a netpolicy are routed by AMSS to the best possible interface using the default netpolicy. Default netpolicy could be pre-defined or provisioned by the administrator or operator. Hence, the default interface could vary from device to device and also depends upon the available networks at any given time.
ルーティング/インターフェース選択決定のすべてがnetpolicyに基づいているだけではなく、宛先アドレスにプライベートIPv4アドレスの重複の問題を避けるために。これはまた、特定のトンネリングシナリオを処理するために、例えば、複数のインターフェイスが同じIPアドレスで構成されることを可能にします。 netpolicyを指定していないアプリケーションは、デフォルトのnetpolicyを使用して可能な限り最高のインターフェイスにAMSSによってルーティングされます。デフォルトnetpolicyは、事前に定義されたか、管理者またはオペレータによってプロビジョニングすることができます。したがって、デフォルトのインターフェイスは、デバイスからデバイスに変えることができ、また、任意の時点で利用可能なネットワークに依存します。
AMSS allows each interface to be configured with its own set of DNS configuration parameters (e.g., list of DNS servers, domain names, etc.). The interface selected to make a DNS resolution is the one to which the application making the DNS query is bound. Applications can also specify a different netpolicy as part of the DNS request to select another interface for DNS resolution. Regardless, all the DNS queries are sent only over this selected interface using the DNS configuration from the interface. DNS resolution is first attempted with the primary server configured in the interface. If a response is not received, the queries are sent to all the other servers configured in the interface in a sequential manner using a backoff mechanism.
AMSSは各インターフェイスがDNS構成パラメータの独自のセットで構成されることを可能にする（例えば、DNSサーバ、ドメイン名などのリスト）。 DNS解決を行うために選択したインターフェイスは、DNSクエリを作成するアプリケーションがバインドされているものです。また、アプリケーションは、DNS解決のための別のインターフェイスを選択するためのDNS要求の一部として異なるnetpolicyを指定することができます。かかわらず、すべてのDNSクエリは、唯一のインタフェースからのDNS設定を使用して、この選択したインタフェースを介して送信されます。 DNS解決は、最初のインターフェイスに設定されたプライマリサーバと試みています。応答が受信されない場合、クエリは、バックオフ機構を用いて順次インターフェイスに設定されているすべての他のサーバーに送信されます。
Arena, a mobile OS based on Linux, provides a connection manager, which is described in [MIF-ARENA] and [MIF-REQS]. The Arena connection manager provides a means for applications to register their connectivity requirement. The connection manager can then choose an interface that matches the application's needs while considering other factors such as availability, cost, and stability. Also, the connection manager can handle multiple-interface issues such as connection sharing.
アリーナ、LinuxベースのモバイルOSは、[MIF-ARENA]および[MIF-REQS]に記載されている接続マネージャを提供します。アリーナの接続マネージャは、アプリケーションが接続要求を登録するための手段を提供します。接続マネージャは、その後、可用性、コスト、および安定性などの他の要因を考慮しながら、アプリケーションのニーズに合ったインターフェースを選択することができます。また、接続マネージャは、接続の共有など、複数のインターフェイスの問題を処理することができます。
Multiple-interface issues also occur in desktop environments in those cases where a desktop host has multiple (logical or physical) interfaces connected to networks with different reachability properties, such as one interface connected to the global Internet, while another interface is connected to a corporate VPN.
別のインターフェイスが、企業に接続されている複数のインターフェイスの問題はまた、デスクトップホストが複数の異なる到達可能性の性質を有するネットワークに接続されている（論理または物理）インターフェース、グローバルインターネットに接続されたものなどのインターフェースを有しているような場合にデスクトップ環境で発生しますVPN。
The multiple-interface functionality currently implemented in Microsoft Windows operation systems is described in more detail in [MULTIHOMING].
現在のMicrosoft Windowsオペレーションシステムに実装され、複数のインターフェイス機能は、[マルチホーミング]でより詳細に記載されています。
It is possible, although not often desirable, to configure default routers on more than one Windows interface. In this configuration, Windows will use the default route on the interface with the lowest routing metric (i.e., the fastest interface). If multiple interfaces share the same metric, the behavior will differ based on the version of Windows in use. Prior to Windows Vista, the packet would be routed out of the first interface that was bound to the TCP/IP stack, the preferred interface. In Windows Vista, host-to-router load sharing [RFC4311] is used for both IPv4 and IPv6.
これは、複数のWindowsインターフェイス上でデフォルトルータを設定するには、ではないが、多くの場合、望ましいことも可能です。この構成では、Windowsは、最小ルーティングメトリック（すなわち、最速インタフェース）とのインタフェース上のデフォルトルートを使用します。複数のインタフェースが同じメトリックを共有している場合、動作は、使用中のWindowsのバージョンに基づいて異なります。 Windows Vistaの前に、パケットがTCP / IPスタック、優先インターフェイスにバインドされた最初のインターフェイスからルーティングされます。 Windows Vistaでは、ホストとルータのロードシェアリング[RFC4311]は、IPv4とIPv6の両方のために使用されています。
If the source address of the outgoing packet has not been determined by the application, Windows will choose from the addresses assigned to its interfaces. Windows implements [RFC3484] for source address selection in IPv6 and, in Windows Vista, for IPv4. Prior to Windows Vista, IPv4 simply chose the first address on the outgoing interface.
発信パケットの送信元アドレスは、アプリケーションによって決定されていない場合、Windowsはそのインターフェイスに割り当てられたアドレスから選択します。 Windowsは、IPv4のために、Windows Vistaでは、IPv6におけるソースアドレス選択のための[RFC3484]を実装しています。 Windows Vistaでは、IPv4のに先立ち、単に発信インターフェイス上の最初のアドレスを選択しました。
For incoming packets, Windows will check if the destination address matches one of the addresses assigned to its interfaces. Windows has implemented the weak host model [RFC1122] on IPv4 in Windows 2000, Windows XP, and Windows Server 2003. The strong host model became the default for IPv4 in Windows Vista and Windows Server 2008; however, the weak host model is available via per-interface configuration. IPv6 has always implemented the strong host model.
宛先アドレスがそのインターフェイスに割り当てられたアドレスのいずれかに一致する場合、着信パケットの場合、Windowsはチェックします。 WindowsがWindows 2000でのIPv4に弱いホストモデル[RFC1122]を実装した、Windows XP、およびWindows Server 2003は、強力なホストモデルは、Windows VistaおよびWindows Server 2008でIPv4のデフォルトになりました。しかし、弱いホストモデルは、インターフェースごとのコンフィギュレーションを介して利用可能です。 IPv6は、常に強力なホストモデルを実装しています。
Windows largely relies on suffixes to solve DNS resolution issues. Suffixes are used for four different purposes:
Windowsは、主にDNS解決の問題を解決するための接尾辞に依存しています。サフィックスは、4つの異なる目的のために使用されます。
1. DNS Suffix Search List (aka domain search list): suffix is added to non-FQDNs (Fully Qualified Domain Names).
1. DNSサフィックス検索一覧（別名ドメイン検索リスト）：接尾辞は非のFQDN（完全修飾ドメイン名）に追加されます。
2. Interface-specific suffix list: allows sending different DNS queries to different DNS servers.
2.インターフェイス固有の接尾辞リスト：別のDNSサーバに異なるDNSクエリを送信することができます。
3. Suffix to control Dynamic DNS Updates: determines which DNS server will receive a dynamic update for a name with a certain suffix.
ダイナミックDNSアップデートを制御する3.サフィックスは：DNSサーバーは、特定の接尾辞で名前の動的更新を受信するかを決定します。
4. Suffix in the Name Resolution Policy Table [NRPT]: aids in identifying a namespace that requires special handling (feature available only after Windows 7 and its server counterpart, Windows Server 2008 R2).
（Windowsのみ7とそのサーバーの対応は、Windows Server 2008 R2の後に利用できる機能）特別な処理を必要とする名前空間を特定するのに役立つ：名前解決ポリシーテーブル[NRPT] 4.サフィックス。
However, this section focuses on the interface-specific suffix list since it is the only suffix usage in the scope of this document.
それはこの文書の範囲でのみ接尾辞の使用状況であるので、このセクションでは、インターフェイス固有のサフィックスリストに焦点を当てています。
DNS configuration information can be host-wide or interface specific. Host-wide DNS configuration is input via static configuration or, in sites that use Active Directory, Microsoft's Group Policy. Interface-specific DNS configuration can be input via static configuration or via DHCP.
DNS設定情報は、ホスト全体またはインターフェイス特定することができます。ホスト全体のDNS設定は、Active Directory、Microsoftのグループポリシーを使用するサイトでは、静的な構成を介して入力されますか。インターフェイス固有のDNS設定は静的な構成を介して、またはDHCPを介して入力することができます。
The host-wide configuration consists of a primary DNS suffix to be used for the local host, as well as a list of suffixes that can be appended to names being queried. Before Windows Vista and Windows Server 2008, there was also a host-wide DNS server list that took precedence over per-interface DNS configuration.
ホスト全体の構成は、ローカルホスト、ならびに照会されている名称に付加することができる接尾辞のリストに使用されるプライマリDNSサフィックスから構成されています。 Windows VistaおよびWindows Server 2008の前に、インターフェースごとのDNSの設定よりも優先されましたホスト全体のDNSサーバーのリストもありました。
The interface-specific DNS configuration comprises an interface-specific suffix list and a list of DNS server IP addresses.
インターフェイス固有のDNS設定は、インターフェイス固有の接尾辞リストとDNSサーバーのIPアドレスのリストを含みます。
Windows uses a host-wide "effective" server list for an actual query, where the effective server list may be different for different names. In the list of DNS server addresses, the first server is considered the "primary" server, with all other servers being secondary.
Windowsは、効果的なサーバーのリストが異なる名前は異なる場合があり実際のクエリのためのホスト全体で「有効」サーバリストを使用しています。 DNSサーバアドレスのリストでは、最初のサーバーは、他のすべてのサーバーが2であることと、「プライマリ」サーバーと見なされます。
When a DNS query is performed in Windows, the query is first sent to the primary DNS server on the preferred interface. If no response is received in one second, the query is sent to the primary DNS servers on all interfaces under consideration. If no response is received for 2 more seconds, the DNS server sends the query to all of the DNS servers on the DNS server lists for all interfaces under consideration. If the host still doesn't receive a response after 4 seconds, it will send to all of the servers again and wait 8 seconds for a response.
DNSクエリがWindowsで実行されると、クエリが第一の好ましいインターフェイス上のプライマリDNSサーバーに送信されます。無応答が1秒間に受信されない場合は、クエリが検討中のすべてのインターフェイス上のプライマリDNSサーバに送信されます。応答が2秒以上のために受信されない場合、DNSサーバは、検討中のすべてのインターフェイスのDNSサーバーのリストにDNSサーバのすべてにクエリを送信します。ホストはまだ4秒後に応答を受信しない場合、それは再びすべてのサーバに送信し、応答を8秒を待ちます。
In addition to the two commonly used routing tables (the local and main routing tables), the kernel can support up to 252 additional routing tables that can be added in the file /etc/iproute2/rt_tables. A routing table can contain an arbitrary number of routes; the selection of route is classically made according to the destination address of the packet. Linux also provides more flexible routing selection based on the type of service, scope, and output interface. In addition, since kernel version 2.2, Linux supports policy-based routing using the multiple routing tables capability and a routing policy database. This database contains routing rules used by the kernel. Using policy-based routing, the source address, the ToS flags, the interface name, and an "fwmark" (a mark added in the data structure representing the packet) can be used as route selectors.
2つの一般的に使用されるルーティングテーブル（ローカルおよびメインルーティングテーブル）に加えて、カーネルは、ファイル/ etc / iproute2の/ rt_tablesで添加することができる最大252個の追加のルーティングテーブルをサポートすることができます。ルーティングテーブルは、ルートの任意の数を含むことができます。経路の選択は、古典的に、パケットの宛先アドレスに従って行われます。 Linuxは、サービス、範囲、および出力インターフェースのタイプに基づいて、より柔軟なルーティング選択を提供します。また、カーネルバージョン2.2以降、Linuxは、複数のルーティングテーブル機能とルーティングポリシーデータベースを使用して、ポリシーベースのルーティングをサポートしています。このデータベースには、カーネルが使用するルーティングルールが含まれています。ポリシーベースのルーティングを使用して、送信元アドレス、ToSのフラグ、インタフェース名、「fwmark」（パケットを表すデータ構造に追加マーク）経路セレクタとして使用することができます。
Policy-based routing can be used in addition to Linux packet-filtering capabilities, e.g., provided by the "iptables" tool. In a multiple-interface context, this tool can be used to mark the packets, i.e., assign a number to fwmark, in order to select the routing rule according to the type of traffic. This mark can be assigned according to parameters like protocol, source and/or destination addresses, port number, and so on.
ポリシーベースのルーティングは「iptablesの」ツールによって提供される、例えば、Linuxのパケットフィルタリング機能に加えて使用することができます。マルチインタフェースのコンテキストでは、このツールは、パケットをマークするために使用することができる、すなわち、トラフィックの種類に応じてルーティングルールを選択するために、fwmarkの番号を割り当てます。このマークは、ように、プロトコル、ソースおよび/または宛先アドレス、ポート番号などのパラメータに応じて割り当てることができます。
Such a routing management framework allows management of complex situations such as address space overlapping. In this situation, the administrator can use packet marking and policy-based routing to select the correct interface.
そのようなルーティング管理フレームワークは、アドレス空間の重なりのような複雑な状況の管理を可能にします。このような状況では、管理者が適切なインターフェイスを選択するために、パケットマーキングとポリシーベースルーティングを使用することができます。
By default, source address selection follows the following basics rules. The initial source address for an outbound packet can be chosen by the application using the bind() call. Without information from the application, the kernel chooses the first address configured on the interface that belongs to the same subnet as the destination address or the next-hop router.
デフォルトでは、送信元アドレス選択には、以下の基本的なルールに従います。アウトバウンドパケットの最初の送信元アドレスがバインド（）コールを使用して、アプリケーションによって選択することができます。アプリケーションからの情報なしに、カーネルは、宛先アドレスまたはネクストホップルータと同じサブネットに属しているインターフェイスで構成された第一のアドレスを選択します。
Linux also implements [RFC3484] for source address selection for IPv6 and dual-stack configurations. However, the address-sorting rules from [RFC3484] are not always adequate. For this reason, Linux allows the system administrator to dynamically change the sorting. This can be achieved with the /etc/gai.conf file.
Linuxはまた、IPv6およびデュアルスタック構成のためのソースアドレス選択のための[RFC3484]を実装しています。ただし、[RFC3484]からのアドレス・ソートのルールは常に十分ではありません。このため、Linuxはシステム管理者が動的にソートを変更することができます。これは/etc/gai.confファイルで達成することができます。
For incoming packets, Linux checks if the destination address matches one of the addresses assigned to its interfaces and then processes the packet according the configured host model. By default, Linux implements the weak host model [RFC1122] on both IPv4 and IPv6. However, Linux can also be configured to support the strong host model.
宛先アドレスがそのインタフェースに割り当てられたアドレスのいずれかと一致した後、設定されたホストモデルに従ってパケットを処理した場合、着信パケットのために、Linuxがチェックします。デフォルトでは、Linuxは、IPv4とIPv6の両方に弱いホストモデル[RFC1122]を実装しています。しかし、Linuxはまた、強力なホストモデルをサポートするように設定することができます。
Most BSD and Linux distributions rely on their DHCP client to handle the configuration of interface-specific information (such as an IP address and netmask) and a set of system-wide configuration information (such a DNS server list, an NTP server list, and default routes). Users of these operating systems have the choice of using any DHCP client available for their platform with an operating system default. This section discusses the behavior of several DHCP clients that may be used with Linux and BSD distributions.
ほとんどのBSDとLinuxディストリビューションは、（IPアドレスやネットマスクなど）インターフェイス固有の情報の設定とシステム全体の構成情報（たとえば、DNSサーバのリスト、NTPサーバリストのセットを処理するために彼らのDHCPクライアントに依存し、デフォルトルート）。これらのオペレーティングシステムのユーザーは、オペレーティングシステムのデフォルトとそのプラットフォーム用に利用可能なDHCPクライアントを使用するかを選択できます。このセクションでは、LinuxやBSDディストリビューションで使用することができるいくつかのDHCPクライアントの動作について説明します。
The Internet Systems Consortium (ISC) DHCP Client [ISCDHCP] and its derivative for OpenBSD [OPENBSDDHCLIENT] can be configured with specific instructions for each interface. However, each time new configuration data is received by the host from a DHCP server, regardless of which interface it is received on, the DHCP client rewrites the global configuration data, such as the default routes and the DNS server list (in /etc/resolv.conf) with the most recent information received. Therefore, the last configured interface always become the primary one. The ISC DHCPv6 client behaves similarly. However, OpenBSD provides two mechanisms that prevent the configuration that the user made manually from being overwritten:
インターネットシステムコンソーシアム（ISC）DHCPクライアント[ISCDHCP]とOpenBSDのためのその誘導体[OPENBSDDHCLIENT]は、各インターフェイスに固有の手順を使用して構成することができます。しかし、毎回新しいコンフィギュレーション・データは関係なく、それが受信したインタフェースの、DHCPサーバからホストによって受信され、DHCPクライアントは、（デフォルトルートおよびDNSサーバーのリストとしてグローバルコンフィギュレーションデータを書き換える内の/ etc / resolv.confの）受信した最新の情報を持ちます。そのため、最後に設定されたインターフェイスは、常にプライマリ1になります。 ISC DHCPv6クライアントも同様に動作します。しかし、OpenBSDは、ユーザが上書きされることから手動で行う構成を防ぐ2つのメカニズムを提供します。
o OPTION MODIFIERS (default, supersede, prepend, and append): this mechanism allows the user to override the DHCP options. For example, the supersede statement defines, for some options, the values the client should always use rather than any value supplied by the server.
Oオプションの修飾子（デフォルト、優先し、先頭に追加、および追加）：このメカニズムは、ユーザがDHCPオプションを上書きすることができます。例えば、より優先文定義は、いくつかのオプションのために、値は、クライアントは常にサーバーによって提供される任意の値ではなく使用する必要があります。
o resolv.conf.tail: this allows the user to append anything to the resolv.conf file created by the DHCP client.
O resolv.conf.tail：これは、ユーザがDHCPクライアントによって作成されたresolv.confファイルには何も追加することができます。
The Phystech dhcpcd client [PHYSTECHDHCPC] behaves similarly to the ISC client. It replaces the DNS server list in /etc/resolv.conf and the default routes each time new DHCP information is received on any interface. However, the -R flag can be used to instruct the client to not replace the DNS servers in /etc/resolv.conf. However, this flag is a global flag for the DHCP server and is therefore applicable to all interfaces. When dhcpd is called with the -R flag, the DNS servers are never replaced.
Phystechはクライアント[PHYSTECHDHCPC]はISCのクライアントと同じように動作DHCPCD。これは/etc/resolv.confにDNSサーバーのリストを置き換え、デフォルトルートは毎回新しいDHCP情報は、任意のインターフェイス上で受信されます。ただし、-Rフラグは/etc/resolv.confにDNSサーバを交換しないようにクライアントに指示するために使用することができます。しかし、このフラグは、DHCPサーバのグローバルフラグであり、したがって、すべてのインターフェイスに適用可能です。 dhcpdのは、-Rフラグで呼び出された場合、DNSサーバを交換されることはありません。
The pump client [PUMP] also behaves similarly to the ISC client. It replaces the DNS servers in /etc/resolv.conf and the default routes each time new DHCP information is received on any interface. However, the nodns and nogateway options can be specified on a per-interface basis, enabling the user to define which interface should be used to obtain the global configuration information.
ポンプクライアント[PUMP]もISCクライアントと同様に動作します。それは/etc/resolv.confの中のDNSサーバおよびたびに新しいDHCP情報は、任意のインターフェイス上で受信されたデフォルトルートを置き換えます。しかし、nodnsとnogatewayオプションは、グローバルコンフィギュレーション情報を取得するために使用すべきインタフェースを定義することをユーザに可能に、インターフェイスごとに指定することができます。
The udhcp client [UDHCP] is often used in embedded platforms based on busybox. The udhcp client behaves similarly to the ISC client. It rewrites default routes and the DNS server list each time new DHCP information is received.
udhcpクライアントは[UDHCP]しばしばbusyboxのに基づいて、組み込みプラットフォームで使用されています。 udhcpクライアントはISCのクライアントと同様に動作します。これは、デフォルトルートとDNSサーバのリストに新しいDHCP情報を受信するたびに書き換えます。
Red Hat-based distributions, such as Red Hat, Centos, and Fedora have a per-interface configuration option (PEERDNS) that indicates that the DNS server list should not be updated based on configuration received on that interface.
こうしたレッドハット、CentOSに、とFedoraなどのRed Hatベースのディストリビューションでは、DNSサーバのリストは、そのインターフェイス上で受信した設定に基づいて更新されるべきでないことを示すインターフェースごとの設定オプション（PEERDNS）を持っています。
Most configurable DHCP clients can be set to define a primary interface; only that interface is used for the global configuration data. However, this is limited, since a mobile host might not always have the same set of interfaces available. Connection managers may help in this situation.
ほとんどの設定可能なDHCPクライアントは、プライマリインターフェイスを定義するために設定することができます。唯一そのインターフェイスは、グローバル・コンフィギュレーション・データに使用されます。モバイルホストは常に使用可能なインターフェイスの同じセットを持っていない可能性がありますので、しかし、これは、限られています。接続マネージャは、このような状況で役立つかもしれません。
Some distributions also have a connection manager. However, most connection managers serve as a GUI to the DHCP client and therefore do not change the functionality described above.
いくつかのディストリビューションにも接続マネージャを持っています。しかし、ほとんどの接続マネージャは、DHCPクライアントにGUIとして機能し、したがって、上記の機能を変更しないでください。
The authors of this document would like to thank following people for their input and feedback: Dan Wing, Hui Deng, Jari Arkko, Julien Laganier, and Steinar H. Gunderson.
ダン・ウィング、ホイ鄧小、ヤリArkko、ジュリアンLaganier、およびSteinar H. Gunderson：この文書の著者は、彼らの入力とフィードバックのために、以下の人々に感謝したいと思います。
This document describes current operating system implementations and how they handle the issues raised in the MIF problem statement. While it is possible that the currently implemented mechanisms described in this document may affect the security of the systems described, this document merely reports on current practice. It does not attempt to analyze the security properties (or any other architectural properties) of the currently implemented mechanisms.
この文書では、現在のオペレーティングシステムの実装を説明し、彼らは、MIFの問題文の中で提起された問題を処理する方法。それは、この文書で説明現在実装メカニズムが記載されたシステムのセキュリティに影響を与える可能性があるということは可能ですが、この文書は、単に現在の慣行に報告します。これは、現在実装機構のセキュリティプロパティ（または任意の他のアーキテクチャ特性）を分析しようとしません。
The following people contributed most of the per-operating system information found in this document:
次の人は、この文書で見つかっごとのオペレーティングシステムの情報のほとんどを寄付しました：
o Marc Blanchet, Viagenie
マルク・ブランシェ、Viagenie
o Hua Chen, Leadcore Technology, Ltd.
O華チェン、Leadcoreテクノロジー株式会社
o Yan Zhang, Leadcore Technology, Ltd.
Oヤンチャン、Leadcoreテクノロジー株式会社
o Shunan Fan, Huawei Technology
お しゅなん ふぁん、 ふあうぇい てｃｈのぉｇｙ
o Jian Yang, Huawei Technology
O建ヤン、華為技術
o Gabriel Montenegro, Microsoft Corporation
お がｂりえｌ もんてねｇろ、 みｃろそｆｔ こｒぽらちおん
o Shyam Seshadri, Microsoft Corporation
OシャムSeshadri、マイクロソフトコーポレーション
o Dave Thaler, Microsoft Corporation
お だゔぇ てゃぇｒ、 みｃろそｆｔ こｒぽらちおん
o Kevin Chin, Microsoft Corporation
お けゔぃん ちん、 みｃろそｆｔ こｒぽらちおん
o Teemu Savolainen, Nokia
いいえテームSavolainenのない、ノキア
o Tao Sun, China Mobile
Oタオ日、中国移動
o George Tsirtsis, Qualcomm
ジョージTsirtsis、クアルコムO
o David Freyermuth, France Telecom
デビッドFreyermuth、フランステレコムO
o Aurelien Collet, Altran
Oオーレリアンコレット、Altran
o Giyeong Son, RIM
O Giyeong息子、RIM
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011.
[RFC6418]ブランシェ、M.とP. Seite、 "複数のインタフェースおよびプロビジョニングドメインの問題に関する声明"、RFC 6418、2011年11月。
[ANDROID] Google Inc., "Android developers: package android.net", <http://developer.android.com/reference/android/net/ ConnectivityManager.html>.
[アンドロイド]グーグル、 "Androidの開発者：パッケージandroid.net"、<http://developer.android.com/reference/android/net/ ConnectivityManager.html>。
[ANDROID-RFC3484] Gunderson, S., "RFC 3484 support for Android", 2010, <http://gitorious.org/0xdroid/bionic/commit/ 9ab75d4cc803e91b7f1b656ffbe2ad32c52a86f9>.
[ANDROID-RFC3484] Gunderson、S.、 "アンドロイド用RFC 3484サポート" 2010年、<http://gitorious.org/0xdroid/bionic/commit/ 9ab75d4cc803e91b7f1b656ffbe2ad32c52a86f9>。
[BLACKBERRY] Research In Motion Limited, "BlackBerry Java Development Environment - Fundamentals Guide: Wireless gateways", <http://na.blackberry.com/eng/ deliverables/5827/Wireless_gateways_447132_11.jsp>.
[ブラックベリー]は、Research In Motion Limited、 "ブラックベリーのJava開発環境 - 基礎ガイド：ワイヤレスゲートウェイ"、<http://na.blackberry.com/eng/成果/ 5827 / Wireless_gateways_447132_11.jsp>。
[ISCDHCP] Internet Software Consortium, "ISC DHCP", <http://www.isc.org/software/dhcp>.
[ISCDHCP]インターネットソフトウェアコンソーシアム、 "ISC DHCP"、<http://www.isc.org/software/dhcp>。
[MIF-ARENA] Zhang, Y., Sun, T., and H. Chen, "Multi-interface Network Connection Manager in Arena Platform", Work in Progress, February 2009.
[MIF-ARENA]チャン、Y.、日、T.、およびH.チェン、 "アリーナ・プラットフォームでのマルチインターフェースネットワーク接続マネージャ"、進歩、2009年2月に作業。
[MIF-REQS] Yang, J., Sun, T., and S. Fan, "Multi-interface Connection Manager Implementation and Requirements", Work in Progress, March 2009.
[MIF-REQS]ヤン、J.、日、T.、およびS.ファン、 "マルチインターフェース接続マネージャの実装と要件"、進歩、2009年3月に作業。
[MULTIHOMING] Montenegro, G., Thaler, D., and S. Seshadri, "Multiple Interfaces on Windows", Work in Progress, March 2009.
[マルチホーミング]モンテネグロ、G.、ターラー、D.、およびS. Seshadri、 "Windows上で複数のインターフェイス"、進歩、2009年3月に作業。
[NRPT] Davies, J., "Name Resolution Policy Table", February 2010, <http://technet.microsoft.com/en-us/magazine/ff394369.aspx>.
[NRPT]デイヴィス、J.、 "名前解決ポリシーテーブル"、2010年2月、<http://technet.microsoft.com/en-us/magazine/ff394369.aspx>。
[OPENBSDDHCLIENT] OpenBSD, "OpenBSD dhclient", <http://www.openbsd.org/>.
[OPENBSDDHCLIENT] OpenBSDの、 "OpenBSDのあるdhclient"、<http://www.openbsd.org/>。
[PHYSTECHDHCPC] Phystech, "dhcpcd", <http://www.phystech.com/download/dhcpcd.html>.
[PHYSTECHDHCPC] Phystech、 "dhcpcdを"、<http://www.phystech.com/download/dhcpcd.html>。
[PUMP] Red Hat, "PUMP", 2009, <http://redhat.com>.
[PUMP]レッドハット、 "PUMP"、2009年、<http://redhat.com>。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[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月。
[RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load Sharing", RFC 4311, November 2005.
[RFC4311] HindenとR.とD.ターラー、 "IPv6ホストツールーター負荷分散"、RFC 4311、2005年11月。
[S60] Nokia Corporation, "S60 Platform: IP Bearer Management", 2007, <http://www.forum.nokia.com/info/ sw.nokia.com/id/190358c8-7cb1-4be3-9321-f9d6788ecae5/ S60_Platform_IP_Bearer_Management_v1_0_en.pdf.html>.
[S60]ノキア・コーポレーション、 "S60プラットフォーム：IPベアラ管理"、2007年、<http://www.forum.nokia.com/info/ sw.nokia.com/id/190358c8-7cb1-4be3-9321-f9d6788ecae5/ S60_Platform_IP_Bearer_Management_v1_0_en.pdf.html>。
[UDHCP] Busybox, "uDHCP", <http://busybox.net/downloads/BusyBox.html>.
[UDHCP] Busyboxの、 "uDHCP"、<http://busybox.net/downloads/BusyBox.html>。
[WINDOWSMOBILE] Microsoft Corporation, "SDK Documentation for Windows Mobile-Based Smartphones: Connection Manager", 2005, <http://msdn.microsoft.com/en-us/library/ aa457829.aspx>.
[WINDOWSMOBILE]マイクロソフト社は、 "Windows Mobileベースのスマートフォン用SDKのドキュメント：接続マネージャ"、2005年、<http://msdn.microsoft.com/en-us/library/ aa457829.aspx>。
[WNDS-RFC3484] Microsoft Corporation, "SDK Documentation for Windows Mobile-Based Smartphones: Default Address Selection for IPv6", April 2010, <http://msdn.microsoft.com/en-us/ library/aa925716.aspx>.
[WNDS-RFC3484]マイクロソフト社は、 "Windows Mobileベースのスマートフォン用SDKのドキュメント：IPv6のデフォルトのアドレス選択"、2010年4月、<http://msdn.microsoft.com/en-us/ライブラリ/ aa925716.aspx>。
Authors' Addresses
著者のアドレス
Margaret Wasserman Painless Security, LLC 356 Abbott Street North Andover, MA 01845 USA
マーガレットワッサーマン無痛セキュリティ、LLC 356アボットストリートノースアンドーヴァー、MA 01845 USA
Phone: +1 781 405-7464 EMail: mrw@painless-security.com URI: http://www.painless-security.com
電話：+1 781 405-7464 Eメール：mrw@painless-security.com URI：http://www.painless-security.com
Pierrick Seite France Telecom - Orange 4, rue du clos courtel BP 91226 Cesson-Sevigne 35512 France
Pierrick Seiteフランステレコム - オレンジ4 RUEドゥクロcourtel BP 91226 35512セッソンセビニェフランス
EMail: pierrick.seite@orange.com
メールアドレス：pierrick.seite@orange.com