[要約] RFC 6419は、複数のインターフェースを持つホストの現在のプラクティスについてのガイドラインです。このRFCの目的は、複数のインターフェースを持つホストの設計と運用に関するベストプラクティスを提供することです。
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
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. 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]、BlackBerry [BlackBerry]など、このドキュメントの両方のモバイルハンドセットとデスクトップオペレーティングシステムの両方を含む、いくつかの広く使用されているオペレーティングシステムに実装されている複数のインターフェイスソリューションに関する公開されています。、Google Android [Android]、Microsoft 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.
単一のシステム全体のリストをサポートするシステムは、複数のDNSサーバーリストを受信する場合に使用するDNSサーバーを選択する方法が異なります（たとえば、複数のインターフェイスのDHCPから）。「プライマリ」インターフェイスで受け取った情報を受け入れる人もいれば、構成された最初のセット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.
一部のシステムでは、異なるインターフェイスの異なるデフォルトルーターリストの構成を許可します。これらのシステムは、2つ以上のインターフェイスが同じルーティングメトリックを持っている場合、最も低いルーティングメトリックを持つインターフェイス上のデフォルトゲートウェイを常に選択します。
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接続の要件が異なります。典型的なシナリオを図1に示します。ここでは、セルラーデバイスがWebブラウジング用のワイヤレスローカルエリアネットワーク（WLAN）アクセスと、マルチメディアメッセージ（MMS）を転送するための一般的なパケットラジオサービス（GPRS）アクセスを利用しています。別の典型的なシナリオは、別のネットワークインターフェイスでのベストエフォートのWebブラウジングと並行して、1つのネットワークインターフェイスを介したリアルタイム音声（VOIP）セッションです。さらに別の典型的なシナリオは、あるネットワークインターフェイスと別のネットワークアクセスを介した1つのネットワークインターフェイスとローカル（企業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 APNS、ダイヤルアップ番号など）用にいくつかのIAPが構成されている場合があります。また、トンネルの確立に必要なパラメーターを定義する「仮想」IAPS（VPNなど）もあります。
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サーバーリストを使用します）。バインドされた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 3rd Edition、Feature Pack 2は、同じ目的地につながるIAPをグループ化するサービスネットワークアクセスポイント（スナップ）の概念を紹介します。これにより、アプリケーション用の宛先ネットワークの静的または手動で選択することができ、スナップ内で利用可能な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).
スナップを使用すると、オペレーティングシステムは、同じ宛先に至る優先IAPが利用可能になったときにアプリケーションに通知できます（たとえば、ユーザーが自宅のWLANアクセスポイントの範囲内に入ったとき）または現在使用されているIAPがもうなくなったときに利用可能。その場合、アプリケーションは別のIAPを介して再接続する必要があります（たとえば、ユーザーが自宅のWLANの範囲外に出て、セルラーネットワークに移動する必要がある場合）。
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よりもIPv4が推奨されます。
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.
Microsoft Windows Mobileは、接続マネージャー[WindowsMobile]を活用して、複数のネットワーク接続を処理します。このアーキテクチャは、ネットワーク接続の確立と管理を集中化および自動化し、接続を自動的に選択し、自動的にまたはユーザーの開始によってダイヤルインし、接続と共有リソースの使用を最適化することを可能にします。接続マネージャーは、接続選択の有効性を定期的に再評価します。Connection Managerは、意思決定において、コスト、セキュリティ、帯域幅、エラー率、遅延などのさまざまな属性を使用します。
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.
バッテリー電源や帯域幅などのリソースの使用を最適化するために、Connection Managerは、アプリケーションが定期的な接続の要件を登録できるようにすることで、ネットワーク接続の使用を同期できるようにします。適切な接続が使用できるようになった場合、アプリケーションに通知されます。
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
Windows Mobile Connection Managementと比較して、Windows Phone 7は、端末を複数のインターフェイスに同時に接続できる場合のルーティング機能を更新します。Windows Phone 7は、メトリックが低いインターフェイスに対応する最初のホップを選択します。複数のインターフェイスがある場合、アプリケーションシステムは、デフォルトで使用可能なインターフェイスの順序付けられたリストから選択します。デフォルトの接続ポリシーは、ワイヤレスよりも有線およびセルラーよりも有線を好みます。したがって、WLANが利用可能なときにアプリケーションがCellular 3Gをアクティブインターフェイスとして使用したい場合、アプリケーションはデフォルトの接続マッピングポリシーをオーバーライドする必要があります。アプリケーション固有のマッピングポリシーは、Microsoft APIを介して設定するか、モバイルオペレーターによってプロビジョニングされます。アプリケーション、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).
セキュリティモデルへのコンプライアンスは、インターフェイス（WLAN、セルラー）、最小インターフェイス速度（X KBIT/S、Y MBIT/S）、または名前（アクセスポイント名）で接続タイプを要求できます。
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.
ネットワークの構成に応じて、Motion in Motion（RIM）BlackBerryデバイス[BlackBerry]のアプリケーション[BlackBerry]は、直接TCP/IP接続または異なるアプリケーションプロキシを使用して、ワイヤレスネットワーク上の接続を確立できます。たとえば、一部のワイヤレスサービスプロバイダーは、インターネットへの直接TCP/IP接続を提供するインターネットゲートウェイを提供しますが、他の一部はWAPでHTTP接続を発生させるワイヤレスアプリケーションプロトコル（WAP）ゲートウェイを提供できます。また、BlackBerry Enterprise Server [BlackBerry]をネットワークゲートウェイとして使用することもできます。 BlackBerry Enterprise Serverは、HTTPおよびTCP/IPプロキシサービスを提供して、アプリケーションがイントラネットまたはインターネットへのHTTPおよびTCP/IP接続を管理するための安全なゲートウェイとして使用できるようにします。インターネットに接続するアプリケーションでは、BlackBerryインターネットサービスまたはワイヤレスサーバープロバイダーのインターネットゲートウェイ、またはWLANを介した直接的なインターネット接続のいずれかを使用して、接続を管理できます。ゲートウェイの選択の問題は、各アプリケーションによって独立して管理されることになっています。たとえば、アプリケーションは常にデフォルトのインターネットゲートウェイを使用するように設計できますが、別のアプリケーションは、利用可能な場合は優先プロキシを使用するように設計できます。
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,
BlackBerryデバイス[BlackBerry]は、複数のネットワークに同時に接続できます（ワイヤレス/有線）。この場合、複数のネットワークインターフェイスを単一のIPスタックまたは複数のIPスタックに関連付けることができます。デバイス、またはアプリケーションは、さまざまな方法で使用するネットワークインターフェイスを選択できます。たとえば、デバイスは常にアプリケーションをデフォルトのネットワークインターフェイス（またはデフォルトアクセスネットワーク）にマッピングできます。複数のIPスタックが複数のインターフェイスに関連付けられている場合、アプリケーションは優先ネットワークインターフェイスに対応するソースアドレスを選択できます。インターフェイスごとのIPスタックでは、オーバーラップアドレススペースを管理することもできます。複数のネットワークインターフェイスが単一のIPスタックに集約されている場合、
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.
デバイスは、各アプリケーションをより適切なネットワークインターフェイスに関連付けます。選択は、コスト、サービスの種類（TOS）、および/またはユーザーの好みに基づいています。
The BlackBerry uses per-interface DNS configuration; applications bound to a specific interface will use the DNS settings for that interface.
BlackBerryは、インターフェイスごとの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.
Androidは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が使用するFile /etc/resolv.confのDNSサーバーをリストしていません。ただし、Linuxごとに、DNS構成がDHCPクライアントに依存できる場合でも、DNS構成はノードスコープです。たとえば、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はWiFiおよび仮想インターフェイスでのみ利用可能であるが、セルラーインターフェイスでは利用できないことに注意する必要があります（IPv4カプセル化にはIPv6なし）。Android 2.2は[Android-RFC3484]で更新されており、[RFC3484]で定義されているアドレス選択ルールの一部を実装しています。すべての[RFC3484]ルールは、規則3（非推奨アドレスを避けてください）、ルール4（ホームアドレスを好む）、およびルール7（ネイティブトランスポートを好む）を除き、サポートされています。また、ルール9（最も長い一致するプレフィックスを使用）が変更されているため、IPv4アドレスをソートしません。
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
Androidリファレンスドキュメントでは、Android.netパッケージ[Android]と、アプリケーションが最初のホップを指定された宛先アドレスに要求するために使用できるConnectivityManagerクラスについて説明します。
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.
指定されたネットワークインターフェイス（第3世代パートナーシッププロジェクト（3GPP）またはWLAN）。また、アプリケーションは、ネットワーク機能の使用を開始する許可をConnection Managerに求めます。接続マネージャーは、ネットワーク接続の変更を監視し、アクティブネットワークへの接続が失われた場合、別のネットワークへのフェイルオーバーを試みます。ネットワーク接続に変更がある場合、アプリケーションに通知されます。アプリケーションは、可用性、タイプ、その他の情報など、すべてのネットワークインターフェイスに関する情報を要求することもできます。
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.
このセクションでは、すべてのQualcommチップセット（モバイルステーションモデム（MSM）、Snapdragonなど）に醸造OSが付属するAdvanced Mobile Station Software（AMSS）によって複数のインターフェイスサポートがどのように処理されるかについて説明します。AMSSは低レベルの接続プラットフォームであり、その上に、メーカーはアプリケーションへの必要な接続を提供するために構築できます。AMSS、オペレーティングシステム、およびアプリケーション間の相互作用モデルは一意ではなく、メーカーが選択した設計に依存します。モバイルOSは、アプリケーションがAMSSを直接（API経由で）直接呼び出すか、アプリケーションのニーズに基づいて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、またはデフォルトの1つになる可能性があります。ネットワークプロファイルは、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
o ネットワーク接続を必要とするアプリケーション目的のネットワークを選択するために、適切なNetPolicyを指定します。NetPolicyは、1つ以上のネットワークインターフェイスと一致する場合があります。AMSSシステム選択モジュールは、コスト、速度、その他のプロビジョニングルールなどのさまざまな基準に基づいて、NetPolicyに一致する最適なインターフェイスを選択します。アプリケーションは明示的に開始します
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 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 アプリケーションは、ネットワークインターフェイスを制御する（例：開始/停止）ために別の接続マネージャーに依存する場合があります。このモデルでは、アプリケーションが必ずしも1つのインターフェイスにバインドされているわけではありません。このようなアプリケーションからのすべてのアウトバウンドパケットは、NetPolicyに一致するインターフェイスの1つにルーティングされます。ルーティングの決定は、各パケットに対して個別に行われ、上記の基準と宛先アドレスに基づいて最適なインターフェイスを選択します。ソースアドレスは、常にパケットの送信に使用されるインターフェイスに割り当てられます。
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を指定しないアプリケーションは、AMSSによってデフォルトのNetPolicyを使用して可能な限り最高のインターフェイスにルーティングされます。デフォルトの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
Linuxに基づいたモバイルOSであるArenaは、[MIF-Arena]および[MIF-Reqs]に記載されている接続マネージャーを提供します。Arena Connection Managerは、アプリケーションが接続要件を登録する手段を提供します。接続マネージャーは、アプリケーションのニーズに合ったインターフェイスを選択できます。
considering other factors such as availability, cost, and stability. Also, the connection manager can handle multiple-interface issues such as connection sharing.
可用性、コスト、安定性などの他の要因を考慮します。また、接続マネージャーは、接続共有などの複数のインターフェイスの問題を処理できます。
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.
デスクトップホストには、グローバルインターネットに接続された1つのインターフェイスなど、異なるリーチ可能性プロパティを持つネットワークに接続された複数の（論理または物理）インターフェイスがある場合、デスクトップ環境ではデスクトップ環境でも複数のインターフェイスの問題が発生します。vpn。
The multiple-interface functionality currently implemented in Microsoft Windows operation systems is described in more detail in [MULTIHOMING].
Microsoft Windows Operation Systemsで現在実装されている複数のインターフェイス機能については、[Multihoming]でより詳細に説明されています。
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では、IPv4とIPv6の両方にホストからルーターへの負荷共有[RFC4311]が使用されています。
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は[RFC3484]をIPv6およびWindows Vistaで、IPv4用のソースアドレス選択のために実装します。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は宛先アドレスがインターフェイスに割り当てられたアドレスの1つと一致するかどうかを確認します。Windowsは、Windows 2000、Windows XP、およびWindows Server 2003のIPv4に弱いホストモデル[RFC1122]を実装しました。強力なホストモデルは、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サフィックス検索リスト（別名ドメイン検索リスト）：接尾辞が非FQDNS（完全資格のドメイン名）に追加されます。
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.
3. ダイナミックDNSの更新を制御するサフィックス：特定の接尾辞を備えた名前の動的更新を受信する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).
4. 名前解像度ポリシーテーブルの接尾辞[NRPT]：特別な取り扱いが必要な名前空間の識別に役立ちます（Windows 7とそのサーバーのカウンターパート、Windows Server 2008 R2の後にのみ利用可能）。
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サーバーアドレスのリストでは、最初のサーバーは「プライマリ」サーバーと見なされ、他のすべてのサーバーはセカンダリです。
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
WindowsでDNSクエリが実行されると、クエリは最初に優先インターフェイス上のプライマリDNSサーバーに送信されます。1秒で応答がない場合、クエリは検討中のすべてのインターフェイスのプライマリDNSサーバーに送信されます。さらに2秒間応答がない場合、DNSサーバーはすべての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サーバーのサーバーリスト。ホストが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.
デフォルトでは、ソースアドレスの選択は、次の基本ルールに従います。アウトバウンドパケットの最初のソースアドレスは、bind（）呼び出しを使用してアプリケーションによって選択できます。アプリケーションからの情報がなければ、カーネルは、宛先アドレスまたはネクストホップルーターと同じサブネットに属するインターフェイスで構成された最初のアドレスを選択します。
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ディストリビューションは、DHCPクライアントに依存して、インターフェイス固有の情報（IPアドレスやネットマスクなど）の構成とシステム全体の構成情報のセット（DNSサーバーリスト、NTPサーバーリスト、およびデフォルトルート）。これらのオペレーティングシステムのユーザーは、オペレーティングシステムのデフォルトでプラットフォームで利用可能な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 /etc /etc /etc /etc /etc /etcResolv.Conf）受信した最新の情報を使用して。したがって、最後に構成されたインターフェイスは常に主要なインターフェイスになります。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 オプション修飾子（デフォルト、SuperSeed、Prepend、およびAppend）：このメカニズムにより、ユーザーはDHCPオプションをオーバーライドできます。たとえば、SuperSeed Statementは、一部のオプションについて、サーバーが提供する値ではなく、クライアントが常に使用する値を定義しています。
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
Phystech DHCPCDクライアント[PhystechDHCPC]は、ISCクライアントと同様に動作します。これは、 /etc /resolv.confのDNSサーバーリストとデフォルトルートを置き換えます。
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.
インターフェース。ただし、-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.
ポンプクライアント[ポンプ]は、ISCクライアントと同様に動作します。任意のインターフェイスで新しいDHCP情報を受信するたびに、 /etc/resolv.confのDNSサーバーとデフォルトルートを置き換えます。ただし、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クライアントと同様に動作します。新しいDHCP情報を受信するたびに、デフォルトのルートとDNSサーバーリストを書き直します。
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.
Red Hat、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.
この文書の著者は、Dan Wing、Hui Deng、Jari Arkko、Julien Laganier、Steinar H. Gundersonなど、Dan Wing、Hui Deng、Jari Arkko、Julien Laganier、Pollowのフォローに感謝します。
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
o マーク・ブランシェ、バイアージェニー
o Hua Chen, Leadcore Technology, Ltd.
o Hua Chen、Leadcore Technology、Ltd。
o Yan Zhang, Leadcore Technology, Ltd.
o Yan Zhang、Leadcore Technology、Ltd。
o Shunan Fan, Huawei Technology
o Shunan Fan、Huawei Technology
o Jian Yang, Huawei Technology
o Jian Yang、Huawei Technology
o Gabriel Montenegro, Microsoft Corporation
o Gabriel Montenegro、Microsoft Corporation
o Shyam Seshadri, Microsoft Corporation
o Shyam Seshadri、Microsoft Corporation
o Dave Thaler, Microsoft Corporation
o Dave Thaler、Microsoft Corporation
o Kevin Chin, Microsoft Corporation
o Microsoft Corporation、Kevin Chin
o Teemu Savolainen, Nokia
o Teemu Savolainen、ノキア
o Tao Sun, China Mobile
o タオ・サン、チャイナ・モバイル
o George Tsirtsis, Qualcomm
o George Tsirtsis、Qualcomm
o David Freyermuth, France Telecom
o フランスのテレコム、デビッド・フレイエルムス
o Aurelien Collet, Altran
o Aurelien Collet、Altran
o Giyeong Son, RIM
o ジヨンの息子、リム
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011.
[RFC6418] Blanchet、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] Google Inc.、「Android Developers：Package 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 Androidのサポート」、2010年、<http://gitorious.org/0xdroid/bionic/commit/ 9ab75d4cc803e91b7f1b1b656ffbe2ad32c52a86f9>
[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>.
[BlackBerry] Research in Motion Limited、「BlackBerry Java開発環境 - 基礎ガイド：ワイヤレスゲートウェイ」、<http://na.blackberry.com/eng/ rubercables/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] Zhang、Y.、Sun、T。、およびH. Chen、「Arena PlatformのMulti-interface Network Connection Manager」、Progress、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] Yang、J.、Sun、T。、およびS. Fan、「マルチインターフェイス接続マネージャーの実装と要件」、2009年3月、進行中の作業。
[MULTIHOMING] Montenegro, G., Thaler, D., and S. Seshadri, "Multiple Interfaces on Windows", Work in Progress, March 2009.
[Multihoming] Montenegro、G.、Thaler、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] Davies、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>.
[ポンプ]レッドハット、「ポンプ」、2009、<http://redhat.com>。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、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。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load Sharing", RFC 4311, November 2005.
[RFC4311] Hinden、R。およびD. Thaler、「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] Nokia Corporation、「S60 Platform：IP Bearer Management」、2007、<http://www.forum.nokia.com/info/ sw.nokia.com/id/190358c8-7cb1-4be3-9321-f9d67888888888888888888888888888888888888888888888888888888888888888888888888888888888888888s60_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] Microsoft Corporation、「Windows MobileベースのスマートフォンのSDKドキュメント：Connection Manager」、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] Microsoft Corporation、「Windows MobileベースのスマートフォンのSDKドキュメント：IPv6のデフォルトアドレス選択」、2010年4月<http://msdn.microsoft.com/en-us/ bribary/aa925716.aspx>。
Authors' Addresses
著者のアドレス
Margaret Wasserman Painless Security, LLC 356 Abbott Street North Andover, MA 01845 USA
マーガレット・ワッサーマンの痛みのないセキュリティ、LLC 356アボットストリートノースアンドーバー、マサチューセッツ州01845 USA
Phone: +1 781 405-7464
EMail: 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 France Telecom -Orange 4、Rue Du Clos Courtel BP 91226 CESSON -SEVIGNE 35512 FRANCE
EMail: pierrick.seite@orange.com