[要約] RFC 7556は、複数のプロビジョニングドメインアーキテクチャに関するものであり、異なるネットワークドメイン間の接続性を向上させるためのガイドラインを提供しています。その目的は、ネットワークの柔軟性と拡張性を向上させ、異なるドメイン間の通信を容易にすることです。
Internet Engineering Task Force (IETF) D. Anipko, Ed.
Request for Comments: 7556 Unaffiliated
Category: Informational June 2015
ISSN: 2070-1721
Multiple Provisioning Domain Architecture
複数のプロビジョニングドメインアーキテクチャ
Abstract
概要
This document is a product of the work of the Multiple Interfaces Architecture Design team. It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously. The framework defines the concept of a Provisioning Domain (PvD), which is a consistent set of network configuration information. PvD-aware nodes learn PvD-specific information from the networks they are attached to and/or other sources. PvDs are used to enable separation and configuration consistency in the presence of multiple concurrent connections.
このドキュメントは、Multiple Interfaces Architecture Designチームの成果物です。複数のネットワークに同時に接続できるノードで発生するいくつかの問題のソリューションフレームワークについて概説します。フレームワークは、ネットワーク構成情報の一貫したセットであるプロビジョニングドメイン（PvD）の概念を定義します。 PvD対応ノードは、接続されているネットワークや他のソースからPvD固有の情報を学習します。 PvDは、複数の同時接続が存在する場合の分離と構成の一貫性を可能にするために使用されます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7556.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7556で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions and Types of PvDs . . . . . . . . . . . . . . . . 5
2.1. Explicit PvDs . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Implicit PvDs and Incremental Adoption of Explicit PvDs . 6
2.3. Relationship between PvDs and Interfaces . . . . . . . . 7
2.4. PvD Identity/Naming . . . . . . . . . . . . . . . . . . . 8
2.5. The Relationship to Dual-Stack Networks . . . . . . . . . 8
3. Conveying PvD Information . . . . . . . . . . . . . . . . . . 9
3.1. Separate Messages or One Message? . . . . . . . . . . . . 9
3.2. Securing PvD Information . . . . . . . . . . . . . . . . 10
3.3. Backward Compatibility . . . . . . . . . . . . . . . . . 10
3.4. Retracting/Updating PvD Information . . . . . . . . . . . 10
3.5. Conveying Configuration Information Using IKEv2 . . . . . 10
4. Example Network Configurations . . . . . . . . . . . . . . . 11
4.1. A Mobile Node . . . . . . . . . . . . . . . . . . . . . . 11
4.2. A Node with a VPN Connection . . . . . . . . . . . . . . 12
4.3. A Home Network and a Network Operator with Multiple PvDs 12
5. Reference Model for the PvD-Aware Node . . . . . . . . . . . 13
5.1. Constructions and Maintenance of Separate PvDs . . . . . 13
5.2. Consistent Use of PvDs for Network Connections . . . . . 14
5.2.1. Name Resolution . . . . . . . . . . . . . . . . . . . 14
5.2.2. Next-Hop and Source Address Selection . . . . . . . . 15
5.2.3. Listening Applications . . . . . . . . . . . . . . . 16
5.2.3.1. Processing of Incoming Traffic . . . . . . . . . 16
5.2.4. Enforcement of Security Policies . . . . . . . . . . 17
5.3. Connectivity Tests . . . . . . . . . . . . . . . . . . . 18
5.4. Relationship to Interface Management and Connection
Managers . . . . . . . . . . . . . . . . . . . . . . . . 18
6. PvD Support in APIs . . . . . . . . . . . . . . . . . . . . . 19
6.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . 20
7. PvD Trust for PvD-Aware Node . . . . . . . . . . . . . . . . 20
7.1. Untrusted PvDs . . . . . . . . . . . . . . . . . . . . . 20
7.2. Trusted PvDs . . . . . . . . . . . . . . . . . . . . . . 20
7.2.1. Authenticated PvDs . . . . . . . . . . . . . . . . . 21
7.2.2. PvDs Trusted by Attachment . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. Informative References . . . . . . . . . . . . . . . . . . . 23
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
Nodes attached to multiple networks may encounter problems from conflicting configuration between the networks or attempts to simultaneously use more than one network. While various techniques are currently used to tackle these problems [RFC6419], in many cases issues may still appear. The Multiple Interfaces Problem Statement document [RFC6418] describes the general landscape and discusses many of the specific issues and scenario details.
複数のネットワークに接続されているノードでは、ネットワーク間での構成の競合や、複数のネットワークを同時に使用しようとすることで問題が発生する場合があります。現在、これらの問題に取り組むためにさまざまな手法が使用されていますが[RFC6419]、多くの場合、まだ問題が発生する可能性があります。 Multiple Interfaces Problem Statementドキュメント[RFC6418]は、一般的な状況を説明し、特定の問題とシナリオの詳細の多くについて説明します。
Problems, enumerated in [RFC6418], can be grouped into 3 categories:
[RFC6418]に列挙されている問題は、3つのカテゴリに分類できます。
1. Lack of consistent and distinctive management of configuration elements associated with different networks.
1. 異なるネットワークに関連付けられた構成要素の一貫した特徴的な管理の欠如。
2. Inappropriate mixed use of configuration elements associated with different networks during a particular network activity or connection.
2. 特定のネットワークアクティビティまたは接続中に、異なるネットワークに関連付けられた構成要素を不適切に混合して使用した。
3. Use of a particular network that is not consistent with the intended use of the network, or the intent of the communicating parties, leading to connectivity failure and/or other undesired consequences.
3. ネットワークの意図された使用、または通信する当事者の意図と一致しない特定のネットワークの使用は、接続障害および/または他の望ましくない結果につながります。
An example of (1) is a single, node-scoped list of DNS server IP addresses learned from different networks leading to failures or delays in resolution of names from particular namespaces; an example of (2) is an attempt to resolve the name of an HTTP proxy server learned from network A using a DNS server learned from network B; and an example of (3) is the use of an employer-provided VPN connection for peer-to-peer connectivity unrelated to employment activities.
（1）の例は、特定の名前空間からの名前の解決に失敗または遅延をもたらす、異なるネットワークから学習したDNSサーバーIPアドレスの単一のノードスコープリストです。 （2）の例は、ネットワークBから学習したDNSサーバーを使用して、ネットワークAから学習したHTTPプロキシサーバーの名前を解決する試みです。 （3）の例は、雇用活動に関係のないピアツーピア接続のための、雇用主が提供するVPN接続の使用です。
This architecture provides solutions to these categories of problems, respectively, by:
このアーキテクチャは、これらのカテゴリの問題に対する解決策をそれぞれ次の方法で提供します。
1. Introducing the formal notion of PvDs, including identity for PvDs, and describing mechanisms for nodes to learn the intended associations between acquired network configuration information elements.
1. PvDのIDを含むPvDの正式な概念の紹介、および取得されたネットワーク構成情報要素間の意図された関連付けを学習するためのノードのメカニズムの説明。
2. Introducing a reference model for PvD-aware nodes that prevents the inadvertent mixed use of configuration information that may belong to different PvDs.
2. 異なるPvDに属する可能性のある構成情報の不注意による混合使用を防止するPvD対応ノードの参照モデルの紹介。
3. Providing recommendations on PvD selection based on PvD identity and connectivity tests for common scenarios.
3. 一般的なシナリオのPvD IDおよび接続テストに基づくPvD選択に関する推奨事項を提供します。
Provisioning Domain: A consistent set of network configuration information. Classically, all of the configuration information available on a single interface is provided by a single source (such as a network administrator) and can therefore be treated as a single provisioning domain. In modern IPv6 networks, multihoming can result in more than one provisioning domain being present on a single link. In some scenarios, it is also possible for elements of the same PvD to be present on multiple links.
プロビジョニングドメイン：一貫したネットワーク構成情報のセット。従来、単一のインターフェースで使用可能なすべての構成情報は、単一のソース（ネットワーク管理者など）によって提供されるため、単一のプロビジョニングドメインとして扱うことができます。最新のIPv6ネットワークでは、マルチホーミングにより、1つのリンク上に複数のプロビジョニングドメインが存在する可能性があります。一部のシナリオでは、同じPvDの要素が複数のリンクに存在することも可能です。
Typical examples of information in a provisioning domain learned from the network are:
ネットワークから学習したプロビジョニングドメインの情報の典型的な例は次のとおりです。
* Source address prefixes for use by connections within the provisioning domain
* プロビジョニングドメイン内の接続で使用する送信元アドレスプレフィックス
* IP address(es) of the DNS server(s)
* DNSサーバーのIPアドレス
* Name of the HTTP proxy server (if available)
* HTTPプロキシサーバーの名前（利用可能な場合）
* DNS suffixes associated with the network
* ネットワークに関連付けられたDNSサフィックス
* Default gateway address
* デフォルトゲートウェイアドレス
PvD-aware node: A node that supports the association of network configuration information into PvDs and the use of these PvDs to serve requests for network connections in ways consistent with the recommendations of this architecture.
PvD対応ノード：ネットワーク構成情報をPvDに関連付け、これらのPvDを使用して、このアーキテクチャの推奨事項と一致する方法でネットワーク接続の要求に対応するノード。
PvD-aware application: An application that contains code and/or application-specific configuration information explicitly aware of the notion of PvD and/or specific types of PvD elements or properties.
PvD対応アプリケーション：PvDおよび/または特定のタイプのPvD要素またはプロパティの概念を明示的に認識しているコードおよび/またはアプリケーション固有の構成情報を含むアプリケーション。
A node may receive explicit information from the network and/or other sources conveying the presence of PvDs and the association of particular network information with a particular PvD. PvDs that are constructed based on such information are referred to as "explicit" in this document.
ノードは、ネットワークおよび/またはPvDの存在および特定のネットワーク情報と特定のPvDの関連付けを伝える他のソースから明示的な情報を受信できます。このような情報に基づいて構築されたPvDは、このドキュメントでは「明示的」と呼ばれます。
Protocol changes or extensions will likely be required to support explicit PvDs through IETF-defined mechanisms. As an example, one could think of one or more DHCP options carrying PvD identity and/or its elements.
IETF定義のメカニズムを通じて明示的なPvDをサポートするには、プロトコルの変更または拡張が必要になる可能性があります。例として、PvD IDやその要素を運ぶ1つ以上のDHCPオプションを考えることができます。
A different approach could be the introduction of a DHCP option that only carries the identity of a PvD. Here, the associations between network information elements with the identity is implemented by the respective protocols, for example, with a Router Discovery [RFC4861] option associating an address range with a PvD. Additional discussion can be found in Section 3.
別のアプローチは、PvDのIDのみを伝送するDHCPオプションの導入です。ここで、アイデンティティとのネットワーク情報要素間の関連付けは、それぞれのプロトコルによって実装されます。たとえば、ルーター範囲[RFC4861]オプションを使用して、アドレス範囲をPvDに関連付けます。追加の議論はセクション3で見つけることができます。
Other examples of a delivery mechanism for PvDs are key exchange or tunneling protocols, such as the Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296] that allows the transport of host configuration information.
PvDの配信メカニズムの他の例は、ホスト構成情報の転送を可能にするインターネットキーエクスチェンジプロトコルバージョン2（IKEv2）[RFC7296]などのキー交換またはトンネリングプロトコルです。
Specific, existing, or new features of networking protocols that enable the delivery of PvD identity and association with various network information elements will be defined in companion design documents.
PvD IDの配信とさまざまなネットワーク情報要素との関連付けを可能にするネットワーキングプロトコルの特定の、既存の、または新しい機能は、関連する設計ドキュメントで定義されます。
Link-specific and/or vendor-proprietary mechanisms for the discovery of PvD information (differing from IETF-defined mechanisms) can be used by nodes either separate from or in conjunction with IETF-defined mechanisms, providing they allow the discovery of the necessary elements of the PvD(s).
PvD情報（IETF定義のメカニズムとは異なる）を検出するためのリンク固有および/またはベンダー固有のメカニズムは、必要な要素の検出を許可する場合、IETF定義のメカニズムとは別のノードまたはIETF定義のメカニズムと組み合わせて使用できます。 PvDの
In all cases, nodes must by default ensure that the lifetime of all dynamically discovered PvD configuration is appropriately limited by relevant events. For example, if an interface media state change is indicated, previously discovered information relevant to that interface may no longer be valid and thus needs to be confirmed or re-discovered.
すべての場合において、ノードはデフォルトで、動的に検出されたすべてのPvD構成のライフタイムが関連するイベントによって適切に制限されるようにする必要があります。たとえば、インターフェイスのメディア状態の変更が示されている場合、そのインターフェイスに関連する以前に検出された情報は有効ではなくなっている可能性があるため、確認または再検出する必要があります。
It is expected that the way a node makes use of PvD information is generally independent of the specific mechanism/protocol that the information was received by.
ノードがPvD情報を利用する方法は、一般に、情報が受信された特定のメカニズム/プロトコルに依存しないことが期待されます。
In some network topologies, network infrastructure elements may need to advertise multiple PvDs. Generally, the details of how this is performed will be defined in companion design documents.
一部のネットワークトポロジでは、ネットワークインフラストラクチャ要素が複数のPvDをアドバタイズする必要がある場合があります。通常、これがどのように実行されるかの詳細は、関連する設計ドキュメントで定義されます。
For the foreseeable future, there will be networks that do not advertise explicit PvD information, because deployment of new features in networking protocols is a relatively slow process.
近い将来、ネットワーキングプロトコルの新機能の導入は比較的遅いプロセスであるため、明示的なPvD情報をアドバタイズしないネットワークが存在するでしょう。
When connected to networks that don't advertise explicit PvD information, a PvD-aware node shall automatically create separate PvDs for received configuration. Such PvDs are referred to in this document as "implicit".
明示的なPvD情報をアドバタイズしないネットワークに接続すると、PvD対応ノードは、受信した構成用に個別のPvDを自動的に作成します。このようなPvDは、このドキュメントでは「暗黙的」と呼ばれます。
Through the use of implicit PvDs, PvD-aware nodes may still provide benefits to their users (when compared to non-PvD-aware nodes) by following the best practices described in Section 5.
暗黙的なPvDを使用することで、PvD対応ノードは、セクション5で説明されているベストプラクティスに従うことにより、ユーザーにメリットを提供できます（非PvD対応ノードと比較した場合）。
PvD-aware nodes shall treat network information from different interfaces, which is not identified as belonging explicitly to some PvD, as belonging to separate PvDs, one per interface.
PvD対応ノードは、特定のPvDに明示的に属しているとは識別されていない、異なるインターフェイスからのネットワーク情報を、インターフェイスごとに1つの個別のPvDに属しているものとして扱います。
Implicit PvDs can also occur in a mixed mode, i.e., where of multiple networks that are available on an attached link, only some advertise PvD information. In this case, the PvD-aware node shall create explicit PvDs from information explicitly labeled as belonging to PvDs. It shall associate configuration information not labeled with an explicit PvD with an implicit PvD(s) created for that interface.
暗黙のPvDは混合モードでも発生する可能性があります。つまり、接続されたリンクで利用可能な複数のネットワークの場合、一部のPvD情報のみがアドバタイズされます。この場合、PvD対応ノードは、PvDに属するものとして明示的にラベル付けされた情報から明示的なPvDを作成します。明示的なPvDでラベル付けされていない構成情報を、そのインターフェース用に作成された暗黙的なPvDに関連付けます。
By default, implicit PvDs are limited to the network configuration information received on a single interface, and by default, one such PvD is formed for each interface. If additional information is available to the host (through mechanisms out of scope of this document), the host may form implicit PvDs with different granularity. For example, PvDs spanning multiple interfaces such as a home network with a router that has multiple internal interfaces or multiple PvDs on a single interface such as a network that has multiple uplink connections.
デフォルトでは、暗黙のPvDは単一のインターフェースで受信されたネットワーク構成情報に制限され、デフォルトでは、そのようなPvDがインターフェースごとに1つ形成されます。 （このドキュメントの範囲外のメカニズムを介して）ホストが追加情報を利用できる場合、ホストは異なる粒度で暗黙のPvDを形成する可能性があります。たとえば、複数の内部インターフェイスを持つルーターを持つホームネットワークなどの複数のインターフェイスにまたがるPvD、または複数のアップリンク接続を持つネットワークなどの単一のインターフェイス上の複数のPvD。
In the simplest case, explicit PvDs will be scoped for configuration related only to a specific interface. However, there is no requirement in this architecture for such a limitation. Explicit PvDs may include information related to more than one interface if the node learns the presence of the same PvD on those interfaces and the authentication of the PvD ID meets the level required by the node policy (authentication of a PvD ID may be also required in scenarios involving only one connected interface and/or PvD; for additional discussion of PvD Trust, see Section 7).
最も単純なケースでは、明示的なPvDのスコープは、特定のインターフェイスにのみ関連する構成になります。ただし、このような制限に対するこのアーキテクチャの要件はありません。明示的なPvDには、ノードがそれらのインターフェースで同じPvDの存在を学習し、PvD IDの認証がノードポリシーで必要なレベルを満たす場合、複数のインターフェースに関連する情報が含まれる場合があります（PvD IDの認証も必要になる場合があります）接続されたインターフェイスまたはPvDが1つだけ含まれるシナリオ。PvDトラストの詳細については、セクション7を参照してください。
This architecture supports such scenarios. Hence, no hierarchical relationship exists between interfaces and PvDs: it is possible for multiple PvDs to be simultaneously accessible over one interface, as well as a single PvD to be simultaneously accessible over multiple interfaces.
このアーキテクチャはそのようなシナリオをサポートします。したがって、インターフェイスとPvDの間に階層関係はありません。複数のPvDに1つのインターフェイスで同時にアクセスでき、単一のPvDに複数のインターフェイスで同時にアクセスできます。
For explicit PvDs, the PvD ID is a value that is or has a high probability of being globally unique and is received as part of PvD information. It shall be possible to generate a human-readable form of the PvD ID to present to the end user, either based on the PvD ID itself or using metadata associated with the ID. For implicit PvDs, the node assigns a locally generated ID with a high probability of being globally unique to each implicit PvD.
明示的なPvDの場合、PvD IDはグローバルに一意である、またはその可能性が高い値であり、PvD情報の一部として受信されます。 PvD ID自体に基づいて、またはIDに関連付けられたメタデータを使用して、人間が読める形式のPvD IDを生成してエンドユーザーに提示することが可能です。暗黙のPvDの場合、ノードはローカルに生成されたIDを、各暗黙のPvDに対してグローバルに一意である可能性が高い確率で割り当てます。
We say that a PvD ID should be, or should have a high probability of being, globally unique. The purpose of this is to make it unlikely that any individual node will ever accidentally see the same PvD name twice if it is not actually referring to the same PvD. Protection against deliberate attacks involving name clashes requires that the name be authenticated (see Section 7.2.1).
PvD IDは、グローバルに一意であるか、または存在する可能性が高い必要があります。これは、実際に同じPvDを参照していない場合、個々のノードが同じPvD名を誤って2回表示する可能性を低くするためです。名前の衝突を含む意図的な攻撃から保護するには、名前を認証する必要があります（セクション7.2.1を参照）。
A PvD-aware node may use these IDs to select a PvD with a matching ID for special-purpose connection requests in accordance with node policy, as chosen by advanced applications, or to present a human-readable representation of the IDs to the end user for selection of PvDs.
PvD対応ノードは、これらのIDを使用して、高度なアプリケーションによって選択されたノードポリシーに従って、特殊用途の接続要求に対して一致するIDを持つPvDを選択するか、人間が読める形式のIDをエンドユーザーに提示します。 PvDの選択用。
A single network provider may operate multiple networks, including networks at different locations. In such cases, the provider may chose whether to advertise single or multiple PvD identities at all or some of those networks as it suits their business needs. This architecture does not impose any specific requirements in this regard.
単一のネットワークプロバイダーが、異なる場所にあるネットワークを含む複数のネットワークを運用している場合があります。そのような場合、プロバイダーは、ビジネスニーズに合わせて、これらのネットワークのすべてまたは一部で単一または複数のPvD IDをアドバタイズするかどうかを選択できます。このアーキテクチャでは、この点に関して特定の要件はありません。
When multiple nodes are connected to the same link with one or more explicit PvDs available, this architecture assumes that the information about all available PvDs is made available by the networks to all the connected nodes. At the same time, connected nodes may have different heuristics, policies, and/or other settings, including their configured sets of trusted PvDs. This may lead to different PvDs actually being used by different nodes for their connections.
複数のノードが1つ以上の明示的なPvDが利用可能な同じリンクに接続されている場合、このアーキテクチャは、利用可能なすべてのPvDに関する情報が、接続されているすべてのノードがネットワークで利用できることを前提としています。同時に、接続されたノードは、設定された信頼済みPvDのセットを含む、異なるヒューリスティック、ポリシー、および/またはその他の設定を持つ場合があります。これにより、実際には異なるPvDが接続のために異なるノードによって使用される可能性があります。
Possible extensions whereby networks advertise different sets of PvDs to different connected nodes are out of scope of this document.
ネットワークがPvDの異なるセットを異なる接続ノードにアドバタイズする可能性のある拡張は、このドキュメントの範囲外です。
When applied to dual-stack networks, the PvD definition allows for multiple PvDs to be created whereby each PvD contains information relevant to only one address family, or for a single PvD containing information for multiple address families. This architecture requires that accompanying design documents describing PvD-related protocol changes must support PvDs containing information from multiple address families. PvD-aware nodes must be capable of creating and using both single-family and multi-family PvDs.
デュアルスタックネットワークに適用すると、PvD定義で複数のPvDを作成できるため、各PvDに1つのアドレスファミリのみに関連する情報、または複数のアドレスファミリの情報を含む単一のPvDを含めることができます。このアーキテクチャでは、PvD関連のプロトコル変更を説明する付属の設計ドキュメントが、複数のアドレスファミリからの情報を含むPvDをサポートする必要があります。 PvD対応ノードは、シングルファミリとマルチファミリの両方のPvDを作成および使用できる必要があります。
For explicit PvDs, the choice of either of these approaches is a policy decision for the network administrator and/or the node user/ administrator. Since some of the IP configuration information that can be learned from the network can be applicable to multiple address families (for instance, DHCPv6 Address Selection Policy Option [RFC7078]), it is likely that dual-stack networks will deploy single PvDs for both address families.
明示的なPvDの場合、これらのアプローチのどちらを選択するかは、ネットワーク管理者および/またはノードユーザー/管理者のポリシー決定です。ネットワークから学習できる一部のIP構成情報は複数のアドレスファミリに適用できるため（たとえば、DHCPv6アドレス選択ポリシーオプション[RFC7078]）、デュアルスタックネットワークは両方のアドレスに単一のPvDを展開する可能性があります家族。
By default for implicit PvDs, PvD-aware nodes shall include multiple IP families into a single implicit PvD created for an interface. At the time of writing, in dual-stack networks it appears to be common practice for the configuration of both address families to be provided by a single source.
暗黙のPvDのデフォルトでは、PvD対応ノードは、インターフェース用に作成された単一の暗黙のPvDに複数のIPファミリを含める必要があります。これを書いている時点では、デュアルスタックネットワークでは、両方のアドレスファミリの構成を単一のソースから提供するのが一般的であるようです。
A PvD-aware node that provides an API to use, enumerate, and inspect PvDs and/or their properties shall provide the ability to filter PvDs and/or their properties by address family.
PvDおよび/またはそれらのプロパティを使用、列挙、および検査するAPIを提供するPvD対応ノードは、アドレスファミリによってPvDおよび/またはそれらのプロパティをフィルタリングする機能を提供するものとします。
DHCPv6 and Router Advertisements (RAs) are the two most common methods of configuring hosts. To support the architecture described in this document, these protocols would need to be extended to convey explicit PvD information. The following sections describe topics that must be considered before finalizing a mechanism to augment DHCPv6 and RAs with PvD information.
DHCPv6とルーターアドバタイズ（RA）は、ホストを構成する最も一般的な2つの方法です。このドキュメントで説明されているアーキテクチャをサポートするには、これらのプロトコルを拡張して、明示的なPvD情報を伝達する必要があります。以下のセクションでは、PvD情報でDHCPv6とRAを拡張するメカニズムを完成させる前に検討する必要があるトピックについて説明します。
When information related to several PvDs is available from the same configuration source, there are two possible ways of distributing this information: One way is to send information from each different provisioning domain in separate messages. The second method is combining the information from multiple PvDs into a single message. The latter method has the advantage of being more efficient but could have problems with authentication and authorization, as well as potential issues with accommodating information not tagged with any PvD information.
複数のPvDに関連する情報が同じ構成ソースから利用できる場合、この情報を配布するには2つの方法があります。1つは、異なるプロビジョニングドメインから個別のメッセージで情報を送信する方法です。 2番目の方法は、複数のPvDからの情報を1つのメッセージに結合することです。後者の方法はより効率的であるという利点がありますが、認証と承認に問題があり、PvD情報でタグ付けされていない情報に対応することで問題が発生する可能性があります。
DHCPv6 [RFC3315] and RAs [RFC3971] both provide some form of authentication to ensure the identity of the source as well as the integrity of the secured message content. While this is useful, determining authenticity does not tell a node whether the configuration source is actually allowed to provide information from a given PvD. To resolve this, there must be a mechanism for the PvD owner to attach some form of authorization token or signature to the configuration information that is delivered.
DHCPv6 [RFC3315]とRA [RFC3971]はどちらも、送信元のIDとセキュリティで保護されたメッセージコンテンツの整合性を保証する何らかの形式の認証を提供します。これは便利ですが、信頼性を決定しても、構成ソースが特定のPvDからの情報を実際に提供できるかどうかはノードに通知されません。これを解決するには、PvD所有者が配信される構成情報に何らかの形式の認証トークンまたは署名を添付するためのメカニズムが必要です。
The extensions to RAs and DHCPv6 should be defined in such a manner that unmodified hosts (i.e., hosts not aware of PvDs) will continue to function as well as they did prior to PvD information being added. This could imply that some information may need to be duplicated in order to be conveyed to legacy hosts. Similarly, PvD-aware hosts need to be able to correctly utilize legacy configuration sources that do not provide PvD information. There are also several initiatives that are aimed at adding some form of additional information to prefixes [DHCPv6-CLASS-BASED-PREFIX] [IPv6-PREFIX-PROPERTIES], and any new mechanism should try to consider coexistence with such deployed mechanisms.
RAとDHCPv6の拡張は、変更されていないホスト（つまり、PvDを認識しないホスト）が、PvD情報が追加される前と同じように機能し続けるように定義する必要があります。これは、レガシーホストに伝達するために一部の情報を複製する必要があることを意味している可能性があります。同様に、PvD対応ホストは、PvD情報を提供しないレガシー構成ソースを正しく利用できる必要があります。プレフィックス[DHCPv6-CLASS-BASED-PREFIX] [IPv6-PREFIX-PROPERTIES]に何らかの形式の追加情報を追加することを目的としたイニシアチブもいくつかあり、新しいメカニズムでは、このようなデプロイされたメカニズムとの共存を検討する必要があります。
After PvD information is provisioned to a host, it may become outdated or superseded by updated information before the hosts would normally request updates. To resolve this requires that the mechanism be able to update and/or withdraw all (or some subset) of the information related to a given PvD. For efficiency reasons, there should be a way to specify that all information from the PvD needs to be reconfigured instead of individually updating each item associated with the PvD.
PvD情報がホストにプロビジョニングされた後、ホストが通常更新を要求する前に、更新された情報によって古くなったり、置き換えられたりする可能性があります。これを解決するには、メカニズムが、特定のPvDに関連するすべての情報（または一部のサブセット）を更新または撤回できる必要があります。効率上の理由から、PvDに関連付けられた各アイテムを個別に更新するのではなく、PvDからのすべての情報を再構成する必要があることを指定する方法が必要です。
IKEv2 [RFC7296] [RFC5739] is another widely used method of configuring host IP information. For IKEv2, the provisioning domain could be implicitly learned from the Identification - Responder (IDr) payloads that the IKEv2 initiator and responder inject during their IKEv2 exchange. The IP configuration may depend on the named IDr. Another possibility could be adding a specific provisioning domain identifying payload extensions to IKEv2. All of the considerations for DHCPv6 and the RAs listed above potentially apply to IKEv2 as well.
IKEv2 [RFC7296] [RFC5739]は、ホストIP情報を構成するために広く使用されているもう1つの方法です。 IKEv2の場合、プロビジョニングドメインは、IKEv2イニシエーターとレスポンダーがIKEv2交換中に挿入する識別-レスポンダー（IDr）ペイロードから暗黙的に学習できます。 IP構成は、指定されたIDrに依存する場合があります。別の可能性は、ペイロード拡張を識別する特定のプロビジョニングドメインをIKEv2に追加することです。上記のDHCPv6とRAに関するすべての考慮事項は、IKEv2にも適用される可能性があります。
Consider a mobile node with two network interfaces: one to the mobile network, the other to the Wi-Fi network. When the mobile node is only connected to the mobile network, it will typically have one PvD, implicit or explicit. When the mobile node discovers and connects to a Wi-Fi network, it will have zero or more (typically one) additional PvD(s).
2つのネットワークインターフェイスを持つモバイルノードを考えてみます。1つはモバイルネットワークに、もう1つはWi-Fiネットワークに接続します。モバイルノードがモバイルネットワークにのみ接続されている場合、通常、暗黙的または明示的な1つのPvDがあります。モバイルノードがWi-Fiネットワークを検出して接続すると、追加のPvDがゼロ以上（通常は1つ）になります。
Some existing OS implementations only allow one active network connection. In this case, only the PvD(s) associated with the active interface can be used at any given time.
一部の既存のOS実装では、アクティブなネットワーク接続が1つしか許可されていません。この場合、アクティブなインターフェイスに関連付けられているPvDのみが、いつでも使用できます。
As an example, the mobile network can explicitly deliver PvD information through the Packet Data Protocol (PDP) context activation process. Then, the PvD-aware mobile node will treat the mobile network as an explicit PvD. Conversely, the legacy Wi-Fi network may not explicitly communicate PvD information to the mobile node. The PvD-aware mobile node will associate network configuration for the Wi-Fi network with an implicit PvD in this case.
例として、モバイルネットワークは、パケットデータプロトコル（PDP）コンテキストアクティベーションプロセスを介してPvD情報を明示的に配信できます。次に、PvD対応のモバイルノードは、モバイルネットワークを明示的なPvDとして扱います。逆に、レガシーWi-Fiネットワークは、モバイルノードにPvD情報を明示的に伝達しない場合があります。この場合、PvD対応のモバイルノードは、Wi-Fiネットワークのネットワーク構成を暗黙のPvDに関連付けます。
The following diagram illustrates the use of different PvDs in this scenario:
次の図は、このシナリオでのさまざまなPvDの使用を示しています。
<----------- Wi-Fi 'Internet' PvD -------->
+---------+
| +-----+ | +-----+ _ __ _ _
| |Wi-Fi| | | | ( ` ) ( ` )_
| |-IF + |----+ |---------------------------( `)
| | | | |Wi-Fi| ( ) ( Internet )
| +-----+ | | AP | ( ) ( )
| | | | ( Service ) ( )
| | +-----+ ( Provider's ) ( )
| | ( Networks - ( )
| +----+ | `_ ) ( )
| |CELL| | ( ) ( )
| |-IF +--|-------------------------------------( )
| | | | (_ __) (_ _)
| +----+ | `- -- `- __ _) -
+---------+
<------- Mobile 'Internet' PvD ----------->
Figure 1: An Example of PvD Use with Wi-Fi and Mobile Interfaces
図1：Wi-FiおよびモバイルインターフェイスでのPvDの使用例
If the node has established a VPN connection, zero or more (typically one) additional PvD(s) will be created. These may be implicit or explicit. The routing to IP addresses reachable within this PvD will be set up via the VPN connection, and the routing of packets to addresses outside the scope of this PvD will remain unaffected. If a node already has N connected PvDs, after the VPN session has been established typically there will be N+1 connected PvDs.
ノードがVPN接続を確立している場合、0個以上（通常は1個）の追加のPvDが作成されます。これらは暗黙的または明示的です。このPvD内で到達可能なIPアドレスへのルーティングはVPN接続を介してセットアップされ、このPvDの範囲外のアドレスへのパケットのルーティングは影響を受けません。ノードにすでにN個の接続されたPvDがある場合、VPNセッションが確立された後、通常、N + 1個の接続されたPvDがあります。
The following diagram illustrates the use of different PvDs in this scenario:
次の図は、このシナリオでのさまざまなPvDの使用を示しています。
<----------- 'Internet' PvD ------>
+--------+
| +----+ | +----+ _ __ _ _
| |Phy | | | | ( ` ) ( ` )_
| |-IF +-|----+ |--------------------( `)
| | | | | | ( ) (_ Internet _)
| +----+ | | | ( ) `- __ _) -
| | |Home| ( Service ) ||
| | |Gate| ( Provider's ) ||
| | |-way| ( Network - ||
| +----+ | | | `_ ) +---------+ +------------+
| |VPN | | | | ( ) | VPN | | |
| |-IF +-|----+ |---------------------+ Gateway |--+ Private |
| | | | | | (_ __) | | | Services |
| +----+ | +----+ `- -- +---------+ +------------+
+--------+
<-------------- Explicit 'VPN' PvD ----->
Figure 2: An Example of PvD Use with VPN
図2：VPNでのPvDの使用例
An operator may use separate PvDs for individual services that they offer to their customers. These may be used so that services can be designed and provisioned to be completely independent of each other, allowing for complete flexibility in combinations of services that are offered to customers.
オペレーターは、顧客に提供する個々のサービスに個別のPvDを使用できます。これらを使用して、サービスを互いに完全に独立するように設計およびプロビジョニングできるため、顧客に提供されるサービスの組み合わせに完全な柔軟性を与えることができます。
From the perspective of the home network and the node, this model is functionally very similar to being multihomed to multiple upstream operators: Each of the different services offered by the service provider is its own PvD with associated PvD information. In this case, the operator may provide a generic/default PvD (explicit or implicit), which provides Internet access to the customer. Additional services would then be provisioned as explicit PvDs for subscribing customers.
ホームネットワークとノードの観点から見ると、このモデルは機能的に、複数のアップストリームオペレーターにマルチホーム化されるのと非常によく似ています。サービスプロバイダーによって提供されるさまざまなサービスはそれぞれ、関連付けられたPvD情報を持つ独自のPvDです。この場合、オペレーターは、顧客にインターネットアクセスを提供するジェネリック/デフォルトPvD（明示的または暗黙的）を提供できます。その後、追加のサービスが、加入している顧客のための明示的なPvDとしてプロビジョニングされます。
The following diagram illustrates this, using video-on-demand as a service-specific PvD:
次の図は、ビデオオンデマンドをサービス固有のPvDとして使用してこれを示しています。
<------ Implicit 'Internet' PvD ------>
+----+ +-----+ _ __ _ _
| | | | ( ` ) ( ` )_
| PC +-----+ |-------------------------( `)
| | | | ( ) (_ Internet _)
+----+ | | ( ) `- __ _) -
|Home | ( Service )
|Gate-| ( Provider's )
|way | ( Network -
+-----+ | | `_ ) +-----------+
| Set-| | | ( ) |ISP Video- |
| Top +----+ |--------------------------+on-Demand |
| Box | | | (_ __) | Service |
+-----+ +-----+ `- -- +-----------+
<-- Explicit 'Video-on-Demand' PvD -->
Figure 3: An Example of PvD Use with Wi-Fi and Mobile Interfaces
図3：Wi-FiおよびモバイルインターフェイスでのPvDの使用例
In this case, the number of PvDs that a single operator could provision is based on the number of independently provisioned services that they offer. Some examples may include:
この場合、単一のオペレーターがプロビジョニングできるPvDの数は、それらが提供する個別にプロビジョニングされたサービスの数に基づいています。いくつかの例が含まれます：
o Real-time packet voice
o リアルタイムのパケット音声
o Streaming video
o ストリーミングビデオ
o Interactive video (n-way video conferencing)
o インタラクティブビデオ（n-wayビデオ会議）
o Interactive gaming
o インタラクティブゲーム
o Best effort / Internet access
o ベストエフォート/インターネットアクセス
It is assumed that normally, the configuration information contained in a single PvD shall be sufficient for a node to fulfill a network connection request by an application, and hence there should be no need to attempt to merge information across different PvDs.
通常、単一のPvDに含まれる構成情報は、ノードがアプリケーションによるネットワーク接続要求を満たすのに十分でなければならないため、異なるPvD間で情報をマージする必要はないはずです。
Nevertheless, even when a PvD lacks some necessary configuration information, merging of information associated with a different PvD(s) shall not be done automatically as this will typically lead to the issues described in [RFC6418].
それにもかかわらず、PvDに必要な構成情報が不足している場合でも、異なるPvDに関連付けられた情報のマージは、[RFC6418]で説明されている問題に通常つながるため、自動的には行われません。
A node may use other sources, for example: node local policy, user input, or other mechanisms not defined by the IETF for any of the following:
ノードは、他のソースを使用する場合があります。たとえば、ノードのローカルポリシー、ユーザー入力、またはIETFで定義されていない以下のメカニズムのメカニズム。
o Construction of a PvD in its entirety (analogous to statically configuring IP on an interface)
o PvD全体の構築（インターフェースでの静的IPの構成に類似）
o Supplementing some or all learned PvDs with particular configuration elements
o 一部またはすべての学習済みPvDを特定の構成要素で補足する
o Merging of information from different PvDs (if this is explicitly allowed by policy)
o 異なるPvDからの情報のマージ（ポリシーで明示的に許可されている場合）
As an example, a node administrator could configure the node to use a specific DNS resolver on a particular interface, or for a particular named PvD. In the case of a per-interface DNS resolver, this might override or augment the DNS resolver configuration for PvDs that are discovered on that interface. Such creation/augmentation of a PvD(s) could be static or dynamic. The specific mechanism(s) for implementing this is outside the scope of this document. Such a merging or overriding of DNS resolver configuration might be contrary to the policy that applies to a special-purpose connection, such as, for example, those discussed in Sections 5.2.1 and 5.2.4. In such cases, either the special-purpose connection should not be used or the merging/overriding should not be performed.
例として、ノード管理者は、特定のインターフェースで、または特定の名前付きPvDに対して特定のDNSリゾルバーを使用するようにノードを構成できます。インターフェースごとのDNSリゾルバーの場合、これは、そのインターフェースで検出されたPvDのDNSリゾルバー構成をオーバーライドまたは拡張する可能性があります。このようなPvDの作成/拡張は、静的または動的です。これを実装するための特定のメカニズムは、このドキュメントの範囲外です。このようなDNSリゾルバー構成のマージまたはオーバーライドは、例えば、セクション5.2.1および5.2.4で説明されているような、特別な目的の接続に適用されるポリシーに反する場合があります。このような場合、専用接続を使用しないか、マージ/オーバーライドを実行しないでください。
PvDs enable PvD-aware nodes to consistently use the correct set of configuration elements to serve specific network requests from beginning to end. This section provides examples of such use.
PvDを使用すると、PvD対応ノードが一貫して正しい構成要素のセットを使用して、特定のネットワーク要求を最初から最後まで処理できます。このセクションでは、そのような使用例を示します。
When a PvD-aware node needs to resolve the name of the destination for use by a connection request, the node could use one or multiple PvDs for a given name lookup.
PvD対応ノードが接続要求で使用するために宛先の名前を解決する必要がある場合、ノードは特定の名前ルックアップに1つまたは複数のPvDを使用できます。
The node shall choose a single PvD if, for example, the node policy required the use of a particular PvD for a specific purpose (e.g., to download a Multimedia Messaging Service (MMS) message using a specific Access Point Name (APN) over a cellular connection or to direct traffic of enterprise applications to a VPN connection to the enterprise network). To make this selection, the node could use a match between the PvD DNS suffix and a Fully Qualified Domain Name (FQDN) that is being resolved or a match of the PvD ID, as determined by the node policy.
たとえば、ノードポリシーが特定の目的で特定のPvDの使用を要求した場合（たとえば、特定のアクセスポイント名（APN）を使用してマルチメディアメッセージングサービス（MMS）メッセージをダウンロードするため）セルラー接続、またはエンタープライズアプリケーションのトラフィックをエンタープライズネットワークへのVPN接続に転送する）。この選択を行うために、ノードは、PvD DNSサフィックスと解決中の完全修飾ドメイン名（FQDN）の間の一致、またはノードポリシーによって決定されるPvD IDの一致を使用できます。
The node may pick multiple PvDs if, for example, the PvDs are for general purpose Internet connectivity, and the node is attempting to maximize the probability of connectivity similar to the Happy Eyeballs [RFC6555] approach. In this case, the node could perform DNS lookups in parallel, or in sequence. Alternatively, the node may use only one PvD for the lookup, based on the PvD connectivity properties, user configuration of preferred Internet PvD, etc.
たとえば、PvDが汎用インターネット接続用であり、ノードがHappy Eyeballs [RFC6555]アプローチと同様に接続の確率を最大化しようとしている場合、ノードは複数のPvDを選択する可能性があります。この場合、ノードはDNSルックアップを並行して、または順番に実行できます。または、ノードは、PvD接続プロパティ、優先インターネットPvDのユーザー構成などに基づいて、ルックアップに1つのPvDのみを使用できます。
If an application implements an API that provides a way of explicitly specifying the desired interface or PvD, that interface or PvD should be used for name resolution (and the subsequent connection attempt), provided that the host's configuration permits this.
アプリケーションが、目的のインターフェイスまたはPvDを明示的に指定する方法を提供するAPIを実装する場合、ホストの構成で許可されていれば、そのインターフェイスまたはPvDを名前解決（およびその後の接続試行）に使用する必要があります。
In either case, by default a node uses information obtained via a name service lookup to establish connections only within the same PvD as the lookup results were obtained.
どちらの場合も、デフォルトでは、ノードはネームサービスルックアップを介して取得した情報を使用して、ルックアップ結果が取得されたのと同じPvD内でのみ接続を確立します。
For clarification, when it is written that the name service lookup results were obtained "from a PvD", it should be understood to mean that the name service query was issued against a name service that is configured for use in a particular PvD. In that sense, the results are "from" that particular PvD.
明確にするために、ネームサービスのルックアップ結果が「PvDから」取得されたと書かれている場合、ネームサービスクエリは、特定のPvDで使用するように構成されたネームサービスに対して発行されたことを意味します。その意味で、結果はその特定のPvDの「から」です。
Some nodes may support transports and/or APIs that provide an abstraction of a single connection, aggregating multiple underlying connections. Multipath TCP (MPTCP) [RFC6182] is an example of such a transport protocol. For connections provided by such transports/ APIs, a PvD-aware node may use different PvDs for servicing that logical connection, provided that all operations on the underlying connections are performed consistently within their corresponding PvD(s).
一部のノードは、単一の接続の抽象化を提供し、複数の基礎となる接続を集約するトランスポートやAPIをサポートする場合があります。マルチパスTCP（MPTCP）[RFC6182]は、このようなトランスポートプロトコルの例です。このようなトランスポート/ APIによって提供される接続の場合、PvD対応ノードは、対応するPvD内で一貫して実行される接続のすべての操作を条件として、その論理接続のサービスに異なるPvDを使用できます。
For the purpose of this example, let us assume that the preceding name lookup succeeded in a particular PvD. For each obtained destination address, the node shall perform a next-hop lookup among routers associated with that PvD. As an example, the node could determine such associations via matching the source address prefixes / specific routes advertised by the router against known PvDs or by receiving an explicit PvD affiliation advertised through a new Router Discovery [RFC4861] option.
この例では、前の名前の検索が特定のPvDで成功したと仮定します。取得した宛先アドレスごとに、ノードはそのPvDに関連付けられたルーター間でネクストホップルックアップを実行します。例として、ノードは、ルーターによってアドバタイズされたソースアドレスプレフィックス/特定のルートを既知のPvDと照合するか、新しいルーター検出[RFC4861]オプションを通じてアドバタイズされた明示的なPvDアフィリエーションを受信することにより、このような関連付けを決定できます。
For each destination, once the best next hop is found, the node selects the best source address according to rules defined in [RFC6724], but with the constraint that the source address must belong to a range associated with the used PvD. If needed, the node would use the prefix policy from the same PvD for selecting the best source address from multiple candidates.
宛先ごとに、最良のネクストホップが見つかると、ノードは[RFC6724]で定義されたルールに従って最良の送信元アドレスを選択しますが、送信元アドレスは使用されるPvDに関連付けられた範囲に属している必要があるという制約があります。必要に応じて、ノードは同じPvDのプレフィックスポリシーを使用して、複数の候補から最適な送信元アドレスを選択します。
When destination/source pairs are identified, they are sorted using the [RFC6724] destination sorting rules and prefix policy table from the used PvD.
宛先/ソースのペアが識別されると、[RFC6724]宛先ソート規則と使用されたPvDのプレフィックスポリシーテーブルを使用してソートされます。
Consider a host connected to several PvDs, running an application that opens a listening socket / transport API object. The application is authorized by the host policy to use a subset of connected PvDs that may or may not be equal to the complete set of the connected PvDs. As an example, in the case where there are different PvDs on the Wi-Fi and cellular interfaces, for general Internet traffic the host could use only one, preferred PvD at a time (and accordingly, advertise to remote peers the host name and addresses associated with that PvD), or it could use one PvD as the default for outgoing connections, while still allowing use of the other PvDs simultaneously.
複数のPvDに接続され、リスニングソケット/トランスポートAPIオブジェクトを開くアプリケーションを実行しているホストを考えてみます。アプリケーションは、ホストポリシーによって、接続されたPvDの完全なセットと同じであるかどうかに関係なく、接続されたPvDのサブセットを使用することを承認されます。例として、Wi-Fiとセルラーインターフェイスに異なるPvDがある場合、一般的なインターネットトラフィックでは、ホストは一度に1つの優先PvDのみを使用できます（したがって、リモートピアにホスト名とアドレスをアドバタイズしますそのPvDに関連付けられている）、または1つのPvDを発信接続のデフォルトとして使用しながら、他のPvDを同時に使用することができます。
Another example is a host with an established VPN connection. Here, security policy could be used to permit or deny an application's access to the VPN PvD and other PvDs.
別の例は、確立されたVPN接続を持つホストです。ここでは、セキュリティポリシーを使用して、VPN PvDおよびその他のPvDへのアプリケーションのアクセスを許可または拒否できます。
For non-PvD-aware applications, the operating system has policies that determine the authorized set of PvDs and the preferred outgoing PvD. For PvD-aware applications, both the authorized set of PvDs and the default outgoing PvD can be determined as the common subset produced between the OS policies and the set of PvD IDs or characteristics provided by the application.
PvD非対応のアプリケーションの場合、オペレーティングシステムには、PvDの許可されたセットと優先送信PvDを決定するポリシーがあります。 PvD対応アプリケーションの場合、承認されたPvDのセットとデフォルトの発信PvDの両方を、OSポリシーと、アプリケーションが提供するPvD IDまたは特性のセットとの間で生成される共通のサブセットとして決定できます。
Application input could be provided on a per-application, per-transport-API-object, or per-transport-API-call basis. The API for application input may have an option for specifying whether the input should be treated as a preference instead of a requirement.
アプリケーション入力は、アプリケーションごと、トランスポートAPIオブジェクトごと、またはトランスポートAPI呼び出しごとに提供できます。アプリケーション入力用のAPIには、入力を要件ではなく設定として扱うかどうかを指定するオプションがあります。
Unicast IP packets are received on a specific IP address associated with a PvD. For multicast packets, the host can derive the PvD association from other configuration information, such as an explicit PvD property or local policy.
ユニキャストIPパケットは、PvDに関連付けられた特定のIPアドレスで受信されます。マルチキャストパケットの場合、ホストは、明示的なPvDプロパティやローカルポリシーなどの他の構成情報からPvDアソシエーションを取得できます。
The node OS or middleware may apply more advanced techniques for determining the resultant PvD and/or authorization of the incoming traffic. Those techniques are outside the scope of this document.
ノードOSまたはミドルウェアは、結果のPvDおよび/または着信トラフィックの許可を決定するためのより高度な技術を適用する場合があります。これらの手法は、このドキュメントの範囲外です。
If the determined receiving PvD of a packet is not in the allowed subset of PvDs for the particular application/transport API object, the packet should be handled in the same way as if there were no listener.
パケットの決定された受信PvDが特定のアプリケーション/トランスポートAPIオブジェクトの許可されたPvDのサブセットにない場合、パケットはリスナーが存在しない場合と同じ方法で処理する必要があります。
For connection-oriented APIs, when the initial incoming packet is received, the packet PvD is remembered for the established connection and used for the handling of outgoing traffic for that connection. While typically connection-oriented APIs use a connection-oriented transport protocol, such as TCP, it is possible to have a connection-oriented API that uses a generally connectionless transport protocol, such as UDP.
接続指向のAPIの場合、最初の着信パケットが受信されると、確立された接続のパケットPvDが記憶され、その接続の発信トラフィックの処理に使用されます。通常、接続指向のAPIはTCPなどの接続指向のトランスポートプロトコルを使用しますが、UDPなどの一般的にコネクションレスのトランスポートプロトコルを使用する接続指向のAPIを使用することもできます。
For APIs/protocols that support multiple IP traffic flows associated with a single transport API connection object (for example, Multipath TCP), the processing rules may be adjusted accordingly.
単一のトランスポートAPI接続オブジェクト（たとえば、マルチパスTCP）に関連付けられた複数のIPトラフィックフローをサポートするAPI /プロトコルの場合、それに応じて処理ルールを調整できます。
For connectionless APIs, the host should provide an API that PvD-aware applications can use to query the PvD associated with the packet. For outgoing traffic on this transport API object, the OS should use the selected outgoing PvDs, determined as described in Sections 5.2.1 and 5.2.2.
コネクションレスAPIの場合、ホストは、PvD対応アプリケーションがパケットに関連付けられたPvDをクエリするために使用できるAPIを提供する必要があります。このトランスポートAPIオブジェクトの送信トラフィックの場合、OSは、セクション5.2.1および5.2.2で説明されているように決定された、選択された送信PvDを使用する必要があります。
By themselves, PvDs do not define, and cannot be used for communication of, security policies. When implemented in a network, this architecture provides the host with information about connected networks. The actual behavior of the host then depends on the host's policies (provisioned through mechanisms out of scope of this document), applied by taking received PvD information into account. In some scenarios, e.g., a VPN, such policies could require the host to use only a particular VPN PvD for some/all of the application's traffic (VPN 'disable split tunneling' also known as 'force tunneling' behavior) or apply such restrictions only to selected applications and allow the simultaneous use of the VPN PvD together with the other connected PvDs by the other or all applications (VPN 'split tunneling' behavior).
PvDは、それ自体ではセキュリティポリシーを定義せず、通信に使用できません。ネットワークに実装すると、このアーキテクチャはホストに接続されたネットワークに関する情報を提供します。ホストの実際の動作は、受信したPvD情報を考慮に入れて適用されるホストのポリシー（このドキュメントの範囲外のメカニズムを通じてプロビジョニングされる）に依存します。 VPNなどの一部のシナリオでは、このようなポリシーでは、アプリケーションのトラフィックの一部またはすべてに特定のVPN PvDのみを使用するようホストに要求する（VPNの「スプリットトンネリングを無効にする」とも呼ばれる「強制トンネリング」動作）、またはそのような制限を適用する選択されたアプリケーションにのみ適用され、他のまたはすべてのアプリケーションによるVPN PvDと他の接続されたPvDの同時使用を許可します（VPNの「スプリットトンネリング」動作）。
Although some PvDs may appear as valid candidates for PvD selection (e.g., good link quality, consistent connection parameters, etc.), they may provide limited or no connectivity to the desired network or the Internet. For example, some PvDs provide limited IP connectivity (e.g., scoped to the link or to the access network) but require the node to authenticate through a web portal to get full access to the Internet. This may be more likely to happen for PvDs that are not trusted by a given PvD-aware node.
一部のPvDは、PvD選択の有効な候補として表示される場合がありますが（たとえば、良好なリンク品質、一貫性のある接続パラメーターなど）、目的のネットワークまたはインターネットへの接続が制限されているか、接続されていません。たとえば、一部のPvDは制限されたIP接続を提供しますが（たとえば、スコープがリンクまたはアクセスネットワークに限定されます）、インターネットに完全にアクセスするには、ノードがWebポータルを介して認証する必要があります。これは、特定のPvD対応ノードによって信頼されていないPvDで発生する可能性が高くなります。
An attempt to use such a PvD may lead to limited network connectivity or application connection failures. To prevent the latter, a PvD-aware node may perform a connectivity test for the PvD before using it to serve application network connection requests. In current implementations, some nodes already implement this, e.g., by trying to reach a dedicated web server (see [RFC6419]).
このようなPvDを使用しようとすると、ネットワーク接続が制限されたり、アプリケーション接続が失敗したりする可能性があります。後者を防ぐために、PvD対応ノードは、PvDを使用してアプリケーションネットワーク接続要求を処理する前に、PvDの接続テストを実行できます。現在の実装では、一部のノードがこれをすでに実装しています。たとえば、専用のWebサーバーに到達しようとするなどです（[RFC6419]を参照）。
Section 5.2 describes how a PvD-aware node shall maintain and use multiple PvDs separately. The PvD-aware node shall perform a connectivity test and, only after validation of the PvD, consider using it to serve application connections requests. Ongoing connectivity tests are also required, since during the IP session, the end-to-end connectivity could be disrupted for various reasons (e.g., L2 problems and IP QoS issues); hence, a connectivity monitoring function is needed to check the connectivity status and remove the PvD from the set of usable PvDs if necessary.
セクション5.2では、PvD対応ノードが複数のPvDを個別に維持および使用する方法について説明します。 PvD対応ノードは接続テストを実行する必要があり、PvDの検証後にのみ、アプリケーション接続要求を処理するためにそれを使用することを検討してください。 IPセッション中に、さまざまな理由（L2の問題やIP QoSの問題など）でエンドツーエンドの接続が中断される可能性があるため、継続的な接続テストも必要です。したがって、接続状況をチェックし、必要に応じて使用可能なPvDのセットからPvDを削除するには、接続監視機能が必要です。
There may be cases where a connectivity test for PvD selection may not be appropriate and should be complemented, or replaced, by PvD selection based on other factors. For example, this could be realized by leveraging some 3GPP and IEEE mechanisms, which would allow the exposure of some PvD characteristics to the node (e.g., 3GPP Access Network Discovery and Selection Function (ANDSF) [TS23402], Access Network Query Protocol (ANQP) [IEEE802.11u]).
PvD選択の接続テストが適切でない場合があり、他の要因に基づくPvD選択によって補完または置換する必要がある場合があります。たとえば、これはいくつかの3GPPおよびIEEEメカニズムを活用することで実現できます。これにより、一部のPvD特性をノードに公開できます（たとえば、3GPPアクセスネットワーク検出および選択機能（ANDSF）[TS23402]、アクセスネットワーククエリプロトコル（ANQP ）[IEEE802.11u]）。
Current devices such as mobile handsets make use of proprietary mechanisms and custom applications to manage connectivity in environments with multiple interfaces and multiple sets of network configuration. These mechanisms or applications are commonly known as connection managers [RFC6419].
モバイルハンドセットなどの現在のデバイスは、独自のメカニズムとカスタムアプリケーションを使用して、複数のインターフェイスと複数のネットワーク構成のセットを持つ環境で接続を管理します。これらのメカニズムまたはアプリケーションは、一般に接続マネージャーとして知られています[RFC6419]。
Connection managers sometimes rely on policy servers to allow a node that is connected to multiple networks to perform network selection. They can also make use of routing guidance from the network (e.g., 3GPP ANDSF [TS23402]). Although connection managers solve some
接続マネージャーは、ポリシーサーバーに依存して、複数のネットワークに接続されているノードがネットワークを選択できるようにする場合があります。また、ネットワークからのルーティングガイダンスを使用することもできます（3GPP ANDSF [TS23402]など）。接続マネージャはいくつかを解決しますが
connectivity problems, they rarely address network selection problems in a comprehensive manner. With proprietary solutions, it is challenging to present coherent behavior to the end user of the device, as different platforms present different behaviors even when connected to the same network, with the same type of interface, and for the same purpose. The architecture described in this document should improve the host's behavior by providing the hosts with tools and guidance to make informed network selection decisions.
接続の問題は、ネットワークの選択の問題に包括的に対処することはめったにありません。独自のソリューションでは、同じネットワークに接続され、同じタイプのインターフェイスを使用し、同じ目的で異なるプラットフォームでも異なる動作を示すため、デバイスのエンドユーザーに一貫した動作を提供することは困難です。このドキュメントで説明するアーキテクチャは、情報に基づいたネットワーク選択の決定を行うためのツールとガイダンスをホストに提供することにより、ホストの動作を改善する必要があります。
For all levels of PvD support in APIs described in this chapter, it is expected that the notifications about changes in the set of available PvDs are exposed as part of the API surface.
この章で説明するAPIのPvDサポートのすべてのレベルで、利用可能なPvDのセットの変更に関する通知がAPIサーフェスの一部として公開されることが期待されています。
Applications are not PvD aware in any manner and only submit connection requests. The node performs PvD selection implicitly, without any application participation, based purely on node-specific administrative policies and/or choices made by the user from a user interface provided by the operating environment, not by the application.
アプリケーションはいかなる方法でもPvDを認識せず、接続要求のみを送信します。ノードは、アプリケーションに参加せずに、アプリケーションではなく、オペレーティング環境によって提供されるユーザーインターフェイスからユーザーが行ったノード固有の管理ポリシーや選択に基づいて、暗黙的にPvD選択を実行します。
As an example, PvD selection can be done at the name service lookup step by using the relevant configuration elements, such as those described in [RFC6731]. As another example, PvD selection could be made based on application identity or type (i.e., a node could always use a particular PvD for a Voice over IP (VoIP) application).
例として、PvDの選択は、[RFC6731]で説明されているような関連する構成要素を使用することにより、ネームサービスのルックアップステップで行うことができます。別の例として、PvDの選択は、アプリケーションのIDまたはタイプに基づいて行うことができます（つまり、ノードは常に特定のPvDをVoice over IP（VoIP）アプリケーションに使用できます）。
Applications indirectly participate in PvD selection by specifying hard requirements and soft preferences. As an example, a real-time communication application intending to use the connection for the exchange of real-time audio/video data may indicate a preference or a requirement for connection quality, which could affect PvD selection (different PvDs could correspond to Internet connections with different loss rates and latencies).
アプリケーションは、ハード要件とソフト設定を指定することにより、間接的にPvD選択に参加します。例として、リアルタイムオーディオ/ビデオデータの交換に接続を使用することを意図しているリアルタイム通信アプリケーションは、PvD選択に影響を与える可能性のある接続品質の優先または要件を示す場合があります（異なるPvDがインターネット接続に対応する場合があります）損失率とレイテンシが異なります）。
Another example is the connection of an infrequently executed background activity, which checks for application updates and performs large downloads when updates are available. For such connections, a cheaper or zero-cost PvD may be preferable, even if such a connection has a higher relative loss rate or lower bandwidth. The node performs PvD selection based on applications' inputs and policies and/or user preferences. Some/all properties of the resultant PvD may be exposed to applications.
別の例は、頻繁に実行されないバックグラウンドアクティビティの接続です。これは、アプリケーションの更新をチェックし、更新が利用可能になると大量のダウンロードを実行します。そのような接続の場合、そのような接続の相対損失率が高いか帯域幅が低い場合でも、より安価な、またはコストのかからないPvDが望ましいことがあります。ノードは、アプリケーションの入力とポリシーおよび/またはユーザー設定に基づいてPvD選択を実行します。結果のPvDの一部またはすべてのプロパティがアプリケーションに公開される場合があります。
PvDs are directly exposed to applications for enumeration and selection. Node polices and/or user choices may still override the applications' preferences and limit which PvD(s) can be enumerated and/or used by the application, irrespective of any preferences that the application may have specified. Depending on the implementation, such restrictions (imposed by node policy and/or user choice) may or may not be visible to the application.
PvDは、列挙と選択のためにアプリケーションに直接公開されます。ノードポリシーおよび/またはユーザーの選択は、アプリケーションが指定した設定に関係なく、アプリケーションの設定をオーバーライドし、アプリケーションで列挙および/または使用できるPvDを制限する場合があります。実装によっては、このような制限（ノードポリシーやユーザーの選択によって課される）がアプリケーションに表示される場合と表示されない場合があります。
Implicit and explicit PvDs for which no trust relationship exists are considered untrusted. Only PvDs that meet the requirements in Section 7.2 are trusted; any other PvD is untrusted.
信頼関係が存在しない暗黙的および明示的なPvDは、信頼されていないと見なされます。セクション7.2の要件を満たすPvDのみが信頼されます。その他のPvDは信頼されていません。
In order to avoid the various forms of misinformation that could occur when PvDs are untrusted, nodes that implement PvD separation cannot assume that two explicit PvDs with the same identifier are actually the same PvD. A node that makes this assumption will be vulnerable to attacks where, for example, an open Wi-Fi hotspot might assert that it was part of another PvD and thereby attempt to draw traffic intended for that PvD onto its own network.
PvDが信頼されていない場合に発生する可能性があるさまざまな形式の誤った情報を回避するために、PvD分離を実装するノードは、同じ識別子を持つ2つの明示的なPvDが実際には同じPvDであると想定できません。この仮定を行うノードは、たとえば、オープンWi-Fiホットスポットが別のPvDの一部であると断定し、それによってそのPvD向けのトラフィックを独自のネットワークに引き込もうとする攻撃に対して脆弱になります。
Since implicit PvD identifiers are synthesized by the node, this issue cannot arise with implicit PvDs.
暗黙のPvD識別子はノードによって合成されるため、この問題は暗黙のPvDでは発生しません。
Mechanisms exist (for example, [RFC6731]) whereby a PvD can provide configuration information that asserts special knowledge about the reachability of resources through that PvD. Such assertions cannot be validated unless the node has a trust relationship with the PvD; therefore, assertions of this type must be ignored by nodes that receive them from untrusted PvDs. Failure to ignore such assertions could result in traffic being diverted from legitimate destinations to spoofed destinations.
PvDがそのPvDを介したリソースの到達可能性に関する特別な知識を表明する構成情報を提供できるメカニズム（たとえば、[RFC6731]）が存在します。ノードがPvDとの信頼関係を持たない限り、そのようなアサーションは検証できません。したがって、このタイプのアサーションは、信頼されていないPvDからアサーションを受け取るノードによって無視される必要があります。このようなアサーションを無視しないと、トラフィックが正当な宛先から偽装された宛先に転送される可能性があります。
Trusted PvDs are PvDs for which two conditions apply: First, a trust relationship must exist between the node that is using the PvD configuration and the source that provided that configuration; this is the authorization portion of the trust relationship. Second, there must be some way to validate the trust relationship. This is the authentication portion of the trust relationship. Two mechanisms for validating the trust relationship are defined.
信頼されたPvDは、2つの条件が適用されるPvDです。最初に、PvD構成を使用しているノードとその構成を提供したソースとの間に信頼関係が存在する必要があります。これは信頼関係の承認部分です。次に、信頼関係を検証する方法がいくつか必要です。これは、信頼関係の認証部分です。信頼関係を検証するための2つのメカニズムが定義されています。
It shall be possible to validate the trust relationship for all advertised elements of a trusted PvD, irrespective of whether the PvD elements are communicated as a whole, e.g., in a single DHCP option, or separately, e.g., in supplementary RA options. The feasibility of mechanisms to implement a trust relationship for all PvD elements will be determined in the respective companion design documents.
PvD要素が全体として、たとえば単一のDHCPオプションで、または個別に、たとえば補足のRAオプションで通信されるかどうかに関係なく、信頼されたPvDのすべてのアドバタイズされた要素の信頼関係を検証することが可能です。すべてのPvD要素の信頼関係を実装するメカニズムの実現可能性は、それぞれの関連する設計ドキュメントで決定されます。
One way to validate the trust relationship between a node and the source of a PvD is through the combination of cryptographic authentication and an identifier configured on the node.
ノードとPvDのソース間の信頼関係を検証する1つの方法は、暗号化認証とノードで構成された識別子を組み合わせることです。
If authentication is done using a public key mechanism such as PKI certificate chain validation or DNS-Based Authentication of Named Entities (DANE), authentication by itself is not enough since theoretically any PvD could be authenticated in this way. In addition to authentication, the node would need configuration to trust the identifier being authenticated. Validating the authenticated PvD name against a list of PvD names configured as trusted on the node would constitute the authorization step in this case.
PKI証明書チェーンの検証や名前付きエンティティのDNSベースの認証（DANE）などの公開キーメカニズムを使用して認証を行う場合、理論的にはどのPvDでもこの方法で認証できるため、認証だけでは不十分です。認証に加えて、ノードは認証される識別子を信頼するための構成が必要になります。この場合、ノードで信頼できるものとして構成されたPvD名のリストに対して認証済みのPvD名を検証すると、承認手順になります。
In some cases, a trust relationship may be validated by some means other than those described in Section 7.2.1 simply by virtue of the connection through which the PvD was obtained. For instance, a handset connected to a mobile network may know through the mobile network infrastructure that it is connected to a trusted PvD. Whatever mechanism was used to validate that connection constitutes the authentication portion of the PvD trust relationship. Presumably, such a handset would be configured from the factory (or else through mobile operator or user preference settings) to trust the PvD, and this would constitute the authorization portion of this type of trust relationship.
場合によっては、PvDが取得された接続を介して、セクション7.2.1で説明されている以外の方法で信頼関係を検証できます。たとえば、モバイルネットワークに接続されているハンドセットは、モバイルネットワークインフラストラクチャを通じて、信頼されたPvDに接続されていることを認識できます。接続がPvD信頼関係の認証部分を構成することを検証するために使用されたメカニズムは何でも。おそらく、そのようなハンドセットは、PvDを信頼するように工場から（またはモバイルオペレーターやユーザー設定を介して）構成され、これがこのタイプの信頼関係の承認部分を構成します。
There are at least three different forms of attacks that can be performed using configuration sources that support multiple provisioning domains.
複数のプロビジョニングドメインをサポートする構成ソースを使用して実行できる攻撃には、少なくとも3つの異なる形式があります。
Tampering with provided configuration information: An attacker may attempt to modify information provided inside the PvD container option. These attacks can easily be prevented by using message integrity features provided by the underlying protocol used to carry the configuration information. For example, SEcure Neighbor Discovery (SEND) [RFC3971] would detect any form of tampering with the RA contents and the DHCPv6 [RFC3315] AUTH option that would detect any form of tampering with the DHCPv6 message contents. This attack can also be performed by a compromised configuration source by modifying information inside a specific PvD, in which case the mitigations proposed in the next subsection may be helpful.
提供された構成情報の改ざん：攻撃者は、PvDコンテナーオプション内で提供された情報を変更しようとする可能性があります。これらの攻撃は、構成情報の伝達に使用される基本的なプロトコルによって提供されるメッセージ整合性機能を使用することで簡単に防止できます。たとえば、SEcure Neighbor Discovery（SEND）[RFC3971]は、RAコンテンツの改ざんの形式を検出し、DHCPv6 [RFC3315] AUTHオプションは、DHCPv6メッセージコンテンツの改ざんの形式を検出します。この攻撃は、特定のPvD内の情報を変更することにより、侵害された構成ソースによって実行されることもあります。その場合、次のサブセクションで提案されている緩和策が役立つ場合があります。
Rogue configuration source: A compromised configuration source, such as a router or a DHCPv6 server, may advertise information about PvDs that it is not authorized to advertise. For example, a coffee shop WLAN may advertise configuration information purporting to be from an enterprise and may try to attract enterprise-related traffic. This may also occur accidentally if two sites choose the same identifier (e.g., "linsky").
不正な構成ソース：ルーターやDHCPv6サーバーなどの侵害された構成ソースは、アドバタイズすることを許可されていないPvDに関する情報をアドバタイズする可能性があります。たとえば、コーヒーショップのWLANは、企業に由来するとする構成情報をアドバタイズし、企業関連のトラフィックを引き寄せようとする場合があります。これは、2つのサイトが同じ識別子（「linsky」など）を選択した場合にも、誤って発生する可能性があります。
In order to detect and prevent this, the client must be able to authenticate the identifier provided by the network. This means that the client must have configuration information that maps the PvD identifier to an identity and must be able to authenticate that identity.
これを検出して防止するには、クライアントはネットワークによって提供された識別子を認証できる必要があります。つまり、クライアントには、PvD識別子をIDにマップする構成情報があり、そのIDを認証できる必要があります。
In addition, the network must provide information the client can use to authenticate the identity. This could take the form of a PKI-based or DNSSEC-based trust anchor, or a key remembered from a previous leap-of-faith authentication of the identifier.
さらに、ネットワークは、クライアントがIDを認証するために使用できる情報を提供する必要があります。これは、PKIベースまたはDNSSECベースのトラストアンカーの形式、または識別子の以前のLeap-of-Faith認証から記憶されたキーの形式を取る可能性があります。
Because the PvD-specific information may come to the network infrastructure with which the client is actually communicating from some upstream provider, it is necessary in this case that the PvD container and its contents be relayed to the client unchanged, leaving the upstream provider's signature intact.
PvD固有の情報は、クライアントが実際にアップストリームプロバイダーから通信しているネットワークインフラストラクチャに到達する可能性があるため、この場合、PvDコンテナーとそのコンテンツを変更せずにクライアントに中継し、アップストリームプロバイダーの署名をそのままにしておく必要があります。 。
Replay attacks: A compromised configuration source or an on-link attacker may try to capture advertised configuration information and replay it on a different link, or at a future point in time. This can be avoided by including a replay protection mechanism such as a timestamp or a nonce inside the PvD container to ensure the validity of the provided information.
リプレイ攻撃：侵害された構成ソースまたはオンリンク攻撃者は、アドバタイズされた構成情報をキャプチャして、別のリンクまたは将来のある時点で再生しようとする可能性があります。これは、提供された情報の有効性を保証するために、PvDコンテナー内にタイムスタンプやノンスなどのリプレイ保護メカニズムを含めることで回避できます。
[DHCPv6-CLASS-BASED-PREFIX] Systems, C., Halwasia, G., Gundavelli, S., Deng, H., Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class based prefix", Work in Progress, draft-bhandari-dhc-class-based-prefix-05, July 2013.
[DHCPv6-CLASS-BASED-PREFIX] Systems、C.、Halwasia、G.、Gundavelli、S.、Deng、H.、Thiebaut、L.、Korhonen、J。、およびI. Farrer、「DHCPv6 class based prefix」 、Work in Progress、draft-bhandari-dhc-class-based-prefix-05、2013年7月。
[IEEE802.11u] IEEE, "Local and Metropolitan networks - specific requirements - Part II: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Amendment 9: Interworking with External Networks", IEEE Std 802.11u, <http://standards.ieee.org/findstds/ standard/802.11u-2011.html>.
[IEEE802.11u] IEEE、「ローカルおよびメトロポリタンネットワーク-特定の要件-パートII：ワイヤレスLANメディアアクセスコントロール（MAC）および物理層（PHY）仕様：修正9：外部ネットワークとの相互作用」、IEEE Std 802.11u、< http://standards.ieee.org/findstds/ standard / 802.11u-2011.html>。
[IPv6-PREFIX-PROPERTIES] Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. Liu, "IPv6 Prefix Mobility Management Properties", Work in Progress, draft-korhonen-dmm-prefix-properties-03, October 2012.
[IPv6-PREFIX-PROPERTIES] Korhonen、J.、Patil、B.、Gundavelli、S.、Seite、P。、およびD. Liu、「IPv6 Prefix Mobility Management Properties」、Work in Progress、draft-korhonen-dmm- prefix-properties-03、2012年10月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<http://www.rfc-editor.org/info/rfc3315>。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <http://www.rfc-editor.org/info/rfc3971>.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B.、and P. Nikander、 "SEcure Neighbor Discovery（SEND）"、RFC 3971、DOI 10.17487 / RFC3971、March 2005、<http：/ /www.rfc-editor.org/info/rfc3971>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<http：/ /www.rfc-editor.org/info/rfc4861>。
[RFC5739] Eronen, P., Laganier, J., and C. Madson, "IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5739, DOI 10.17487/RFC5739, February 2010, <http://www.rfc-editor.org/info/rfc5739>.
[RFC5739] Eronen、P.、Laganier、J。、およびC. Madson、「IPv6 Configuration in Internet Key Exchange Protocol Version 2（IKEv2）」、RFC 5739、DOI 10.17487 / RFC5739、2010年2月、<http：// www .rfc-editor.org / info / rfc5739>。
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, <http://www.rfc-editor.org/info/rfc6182>.
[RFC6182] Ford、A.、Raiciu、C.、Handley、M.、Barre、S.、J。Iyengar、「マルチパスTCP開発のアーキテクチャガイドライン」、RFC 6182、DOI 10.17487 / RFC6182、2011年3月、<http ：//www.rfc-editor.org/info/rfc6182>。
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, DOI 10.17487/RFC6418, November 2011, <http://www.rfc-editor.org/info/rfc6418>.
[RFC6418] Blanchet、M。およびP. Seite、「Multiple Interfaces and Provisioning Domains Problem Statement」、RFC 6418、DOI 10.17487 / RFC6418、2011年11月、<http://www.rfc-editor.org/info/rfc6418> 。
[RFC6419] Wasserman, M. and P. Seite, "Current Practices for Multiple-Interface Hosts", RFC 6419, DOI 10.17487/RFC6419, November 2011, <http://www.rfc-editor.org/info/rfc6419>.
[RFC6419] Wasserman、M。、およびP. Seite、「Current- Practices for Multiple-Interface Hosts」、RFC 6419、DOI 10.17487 / RFC6419、2011年11月、<http://www.rfc-editor.org/info/rfc6419> 。
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2012, <http://www.rfc-editor.org/info/rfc6555>.
[RFC6555] Wing、D.、A。Yourtchenko、「Happy Eyeballs：Success with Dual-Stack Hosts」、RFC 6555、DOI 10.17487 / RFC6555、2012年4月、<http://www.rfc-editor.org/info/ rfc6555>。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
[RFC6724] Thaler、D.、Ed。、Draves、R.、Matsumoto、A。、およびT. Chown、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 6724、DOI 10.17487 / RFC6724、2012年9月、<http://www.rfc-editor.org/info/rfc6724>。
[RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved Recursive DNS Server Selection for Multi-Interfaced Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, <http://www.rfc-editor.org/info/rfc6731>.
[RFC6731] Savolainen、T.、Kato、J。、およびT. Lemon、「Improved Recursive DNS Server Selection for Multi-Interfaced Nodes」、RFC 6731、DOI 10.17487 / RFC6731、2012年12月、<http：//www.rfc -editor.org/info/rfc6731>。
[RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing Address Selection Policy Using DHCPv6", RFC 7078, DOI 10.17487/RFC7078, January 2014, <http://www.rfc-editor.org/info/rfc7078>.
[RFC7078]マツモトA.、藤崎T.、およびT. Chown、「DHCPv6を使用したアドレス選択ポリシーの配布」、RFC 7078、DOI 10.17487 / RFC7078、2014年1月、<http://www.rfc-editor.org / info / rfc7078>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「Internet Key Exchange Protocol Version 2（IKEv2）」、STD 79、RFC 7296、DOI 10.17487 / RFC7296 、2014年10月、<http://www.rfc-editor.org/info/rfc7296>。
[TS23402] 3GPP, "Technical Specification Group Services and System Aspects; Architecture enhancements for non-3GPP accesses", Release 12, 3GPP TS 23.402, 2014.
[TS23402] 3GPP、「技術仕様グループサービスとシステムの側面、非3GPPアクセスのアーキテクチャの強化」、リリース12、3GPP TS 23.402、2014。
Acknowledgments
謝辞
The authors would like to thank (in no specific order) Ian Farrer, Markus Stenberg, and Mikael Abrahamsson for their review and comments.
著者は、レビューとコメントを提供してくれたIan Farrer、Markus Stenberg、Mikael Abrahamssonに（順不同で）感謝します。
Contributors
貢献者
The following individuals contributed to this document (listed in no specific order): Alper Yegin (alper.yegin@yegin.org), Aaron Yi Ding (yding@cs.helsinki.fi), Zhen Cao (caozhenpku@gmail.com), Dapeng Liu (liudapeng@chinamobile.com), Dave Thaler (dthaler@microsoft.com), Dmitry Anipko (dmitry.anipko@gmail.com), Hui Deng (denghui@chinamobile.com), Jouni Korhonen (jouni.nospam@gmail.com), Juan Carlos Zuniga (JuanCarlos.Zuniga@InterDigital.com), Konstantinos Pentikousis (k.pentikousis@huawei.com), Marc Blanchet (marc.blanchet@viagenie.ca), Margaret Wasserman (margaretw42@gmail.com), Pierrick Seite (pierrick.seite@orange.com), Suresh Krishnan (suresh.krishnan@ericsson.com), Teemu Savolainen (teemu.savolainen@nokia.com), Ted Lemon (ted.lemon@nominum.com), and Tim Chown (tjc@ecs.soton.ac.uk).
次の個人がこのドキュメントに寄稿しました（順不同）。AlperYegin（alper.yegin@yegin.org）、Aaron Yi Ding（yding@cs.helsinki.fi）、Zhen Cao（caozhenpku@gmail.com）、 Dapeng Liu（liudapeng@chinamobile.com）、Dave Thaler（dthaler@microsoft.com）、Dmitry Anipko（dmitry.anipko@gmail.com）、Hui Deng（denghui@chinamobile.com）、Jouni Korhonen（jouni.nospam@gmail） .com）、Juan Carlos Zuniga（JuanCarlos.Zuniga@InterDigital.com）、Konstantinos Pentikousis（k.pentikousis@huawei.com）、Marc Blanchet（marc.blanchet@viagenie.ca）、Margaret Wasserman（margaretw42@gmail.com） 、Pierrick Seite（pierrick.seite@orange.com）、Suresh Krishnan（suresh.krishnan@ericsson.com）、Teemu Savolainen（teemu.savolainen@nokia.com）、Ted Lemon（ted.lemon@nominum.com）、およびTim Chown（tjc@ecs.soton.ac.uk）。
Author's Address
著者のアドレス
Dmitry Anipko (editor) Unaffiliated
Dmitry Anipko（編集者）無関係
Phone: +1 425 442 6356
EMail: dmitry.anipko@gmail.com