[要約] 要約：RFC 5687は、GEOPRIV Layer 7 Location Configuration Protocolの問題と要件について説明しています。 目的：このRFCの目的は、位置情報の設定プロトコルの問題を特定し、それに対する要件を定義することです。
Internet Engineering Task Force (IETF) H. Tschofenig
Request for Comments: 5687 Nokia Siemens Networks
Category: Informational H. Schulzrinne
ISSN: 2070-1721 Columbia University
March 2010
GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements
GEOPRIVレイヤー7位置構成プロトコル：問題のステートメントと要件
Abstract
概要
This document provides a problem statement, lists requirements, and captures design aspects for a GEOPRIV Layer 7 (L7) Location Configuration Protocol (LCP). This protocol aims to allow an end host to obtain location information, by value or by reference, from a Location Information Server (LIS) that is located in the access network. The obtained location information can then be used for a variety of different protocols and purposes. For example, it can be used as input to the Location-to-Service Translation (LoST) Protocol or to convey location within the Session Initiation Protocol (SIP) to other entities.
このドキュメントは、問題のステートメントを提供し、要件をリストし、Geoprivレイヤー7（L7）位置構成プロトコル（LCP）の設計側面をキャプチャします。このプロトコルは、アクセスネットワークにあるロケーション情報サーバー（LIS）から、値または参照によって、エンドホストが位置情報を取得できるようにすることを目的としています。取得した位置情報は、さまざまな異なるプロトコルと目的に使用できます。たとえば、場所からサービスへの翻訳（失われた）プロトコルへの入力として、またはセッション開始プロトコル（SIP）内の場所を他のエンティティに伝えるために使用できます。
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/rfc5687.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5687で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Scenarios .......................................................4
3.1. Fixed-Wired Environment ....................................4
3.2. Mobile Network .............................................7
3.3. Wireless Access ............................................8
4. Discovery of the Location Information Server ....................9
5. Identifier for Location Determination ..........................11
6. Requirements ...................................................14
7. Security Considerations ........................................16
8. Contributors ...................................................17
9. Acknowledgements ...............................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................18
This document provides a problem statement, lists requirements, and captures design aspects for a GEOPRIV Layer 7 (L7) Location Configuration Protocol (LCP). The protocol has two purposes:
このドキュメントは、問題のステートメントを提供し、要件をリストし、Geoprivレイヤー7（L7）位置構成プロトコル（LCP）の設計側面をキャプチャします。プロトコルには2つの目的があります。
o It is used by a device to obtain its own location (referred as "Location by Value" or LbyV) from a dedicated node, called the Location Information Server (LIS).
o デバイスで使用され、専用ノード（Location Information Server（LIS））から独自の場所（「値による場所」またはLBYVと呼ばれます）を取得します。
o It enables the device to obtain a reference to location information (referred as "Location by Reference" or LbyR). This reference can take the form of a subscription URI, such as a SIP presence-based Uniform Resource Identifier (URI), an HTTP/HTTPS URI, or another URI. The requirements related to the task of obtaining an LbyR are described in a separate document, see [LBYR-REQS].
o これにより、デバイスは位置情報（「参照による場所」またはLBYRと呼ばれる）への参照を取得できます。この参照は、SIPプレゼンスベースのユニフォームリソース識別子（URI）、HTTP/HTTPS URI、または別のURIなど、サブスクリプションURIの形を取得できます。LBYRを取得するタスクに関連する要件は、別のドキュメントで説明されています。[lbyr-reqs]を参照してください。
The need for these two functions can be derived from the scenarios presented in Section 3.
これらの2つの機能の必要性は、セクション3に示されているシナリオから導き出すことができます。
For this document, we assume that the GEOPRIV Layer 7 LCP runs between the device and the LIS.
このドキュメントでは、Geoprivレイヤー7 LCPがデバイスとLISの間で実行されると想定しています。
This document is structured as follows. Section 4 discusses the challenge of discovering the LIS in the access network. Section 5 compares different types of identifiers that can be used to retrieve location information. A list of requirements for the L7 LCP can be found in Section 6.
このドキュメントは次のように構成されています。セクション4では、アクセスネットワークでLISを発見するという課題について説明します。セクション5では、位置情報の取得に使用できるさまざまなタイプの識別子を比較します。L7 LCPの要件のリストは、セクション6に記載されています。
This document does not describe how the access network provider determines the location of the device since this is largely a matter of the capabilities of specific link-layer technologies or certain deployment environments.
このドキュメントでは、アクセスネットワークプロバイダーがデバイスの位置をどのように決定するかは説明されていません。これは、特定のリンク層テクノロジーまたは特定の展開環境の機能の主な問題であるためです。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119], with the qualification that unless otherwise stated these words apply to the design of the GEOPRIV Layer 7 Location Configuration Protocol.
このドキュメントでは、キーワードが「必要はない」、「必須」、「「必要」」、「しなければ」、「そうしない」、「そうすべき」、「そうでない」、「推奨」、「5月」、および「オプション」RFC 2119 [RFC2119]に記載されているとおりに解釈されるべきであり、特に明記しない限り、これらの単語はGeopriv Layer 7ロケーション構成プロトコルの設計に適用されます。
The term Location Information Server (LIS) refers to an entity capable of determining the location of a device and of providing that location information, a reference to it, or both via the Location Configuration Protocol (LCP) to the Target.
Location Information Server（LIS）という用語は、デバイスの場所を決定し、その位置情報、それへの参照、またはその両方をターゲットに介してその両方を提供できるエンティティを指します。
This document also uses terminology from [RFC5012] (such as Internet Access Provider (IAP), Internet Service Provider (ISP), and Application Service Provider (ASP)).
このドキュメントでは、[RFC5012]（インターネットアクセスプロバイダー（IAP）、インターネットサービスプロバイダー（ISP）、アプリケーションサービスプロバイダー（ASP）など）の用語も使用しています。
With the term "Access Network Provider" we refer to the IAP and the ISP) without further distinguishing these two entities, as it is not relevant for the purpose of this document. An additional requirements document on LIS-to-LIS protocol [LIS2LIS] shows a scenario where the separation between IAP and ISP is important.
「アクセスネットワークプロバイダー」という用語を使用すると、このドキュメントの目的に関連していないため、これら2つのエンティティをさらに区別することなく、IAPとISPを参照します。LIS-to-LISプロトコル[LIS2LIS]に関する追加の要件ドキュメントは、IAPとISPの分離が重要なシナリオを示しています。
This section describes a few network scenarios where the L7 LCP may be used. Note that this section does not aim to exhaustively list all possible deployment environments. Instead, we focus on the following environments:
このセクションでは、L7 LCPを使用できるいくつかのネットワークシナリオについて説明します。このセクションでは、可能なすべての展開環境を完全にリストすることを目的としていないことに注意してください。代わりに、次の環境に焦点を当てます。
o DSL/Cable networks, WiMAX-like (Worldwide Interoperability for Microwave Access) fixed access
o DSL/ケーブルネットワーク、WIMAXのような（電子レンジアクセスのための世界的な相互運用性）固定アクセス
o Airport, city, campus wireless networks, such as 802.11a/b/g, 802.16e/WiMAX
o 空港、都市、キャンパスワイヤレスネットワーク802.11a/b/g、802.16e/wimax
o 3G networks
o 3Gネットワーク
o Enterprise networks
o エンタープライズネットワーク
Note that we use the term 'host' instead of device for better readability.
読みやすくするために、デバイスの代わりに「ホスト」という用語を使用することに注意してください。
Figure 1 shows a Digital Subscriber Line (DSL) network scenario with the Access Network Provider and the customer premises. The Access Network Provider operates link- and network-layer devices (represented as a node) and the LIS.
図1は、アクセスネットワークプロバイダーと顧客施設を使用したデジタルサブスクライバーライン（DSL）ネットワークシナリオを示しています。Access Network Providerは、リンクおよびネットワークレイヤーデバイス（ノードとして表される）とLISを操作します。
+---------------------------+
| |
| Access Network Provider |
| |
| +--------+ |
| | Node | |
| +--------+ +----------+ |
| | | | LIS | |
| | +---| | |
| | +----------+ |
| | |
+-------+-------------------+
| Wired Network
<----------------> Access Network Provider demarc
|
+-------+-------------------+
| | |
| +-------------+ |
| | NTE | |
| +-------------+ |
| | |
| | |
| +--------------+ |
| | Device with | Home |
| | NAPT and | Router |
| | DHCP server | |
| +--------------+ |
| | |
| | |
| +------+ |
| | Host | |
| +------+ |
| |
|Customer Premises Network |
| |
+---------------------------+
Figure 1: Fixed-Wired Scenario
図1：固定線のシナリオ
The customer premises network consists of a router with a Network Address Translator with Port Address Translation (NAPT) and a DHCP server as used in most Customer Premises Networks (CPNs) and the Network Termination Equipment (NTE) where Layer 1 and sometimes Layer 2 protocols are terminated. The router in the home network (e.g., broadband router, cable or DSL router) typically runs a NAPT and a DHCP server. The NTE is a legacy device and in many cases cannot be modified for the purpose of delivering location information to the host. The same is true of the device with the NAPT and DHCP server.
顧客施設ネットワークは、ポートアドレス翻訳（NAPT）を備えたネットワークアドレス翻訳者を備えたルーターと、ほとんどの顧客施設ネットワーク（CPN）で使用されるDHCPサーバーと、レイヤー1およびレイヤー2プロトコルを備えたネットワーク終了機器（NTE）で構成されています。終了します。ホームネットワーク内のルーター（ブロードバンドルーター、ケーブル、またはDSLルーターなど）は、通常、NAPTおよびDHCPサーバーを実行します。NTEはレガシーデバイスであり、多くの場合、ホストに位置情報を配信する目的で変更することはできません。同じことが、NAPTおよびDHCPサーバーを備えたデバイスにも当てはまります。
It is possible for the NTE and the home router to physically be in the same box, or for there to be no home router, or for the NTE and host to be in the same physical box (with no home router). An example of this last case is where Ethernet service is delivered to customers' homes, and the Ethernet network interface card (NIC) in their PC serves as the NTE.
NTEとホームルーターが物理的に同じボックスにあること、またはホームルーターがない場合、またはNTEとホストが同じ物理ボックス（ホームルーターなし）にあることが可能です。この最後のケースの例は、イーサネットサービスが顧客の家に配信される場所であり、PCのイーサネットネットワークインターフェイスカード（NIC）がNTEとして機能します。
Current CPN deployments generally fall into one of the following classifications:
現在のCPN展開は、一般に次の分類のいずれかに分類されます。
1. Single PC
1. 単一のPC
1. with Ethernet network interface card (NIC), with Point-to-Point Protocol Over Ethernet (PPPoE), or Dynamic Host Configuration Protocol (DHCP) on PC; there may be a bridged DSL or cable modem as the NTE, or the Ethernet NIC might be the NTE.
1. イーサネットネットワークインターフェイスカード（NIC）を使用して、イーサネット上のポイントツーポイントプロトコル（PPPOE）、またはPC上の動的ホスト構成プロトコル（DHCP）を使用します。nteとして架橋されたDSLまたはケーブルモデムがあるか、イーサネットNICがNTEである可能性があります。
2. with USB-based DSL access or a cable modem access using Point-to-Point Protocol over ATM (PPPoA), PPPoE, or DHCP on PC.
2. PC上のATM（PPPOA）、PPPOE、またはDHCPを介したポイントツーポイントプロトコルを使用したUSBベースのDSLアクセスまたはケーブルモデムアクセス。
Note that the device with NAPT and DHCP of Figure 1 is not present in such a scenario.
図1のNAPTとDHCPを備えたデバイスは、このようなシナリオには存在しないことに注意してください。
2. One or more hosts with at least one router (DHCP client or PPPoE, DHCP server in router; Voice over IP (VoIP) can be a soft client on a PC, a stand-alone VoIP device, or an Analog Terminal Adaptor (ATA) function embedded in a router):
2. 少なくとも1つのルーター（DHCPクライアントまたはPPPOE、ルーターのDHCPサーバー、Voice Over IP（VoIP）を持つ1つ以上のホストは、PCのソフトクライアント、スタンドアロンVoIPデバイス、またはアナログ端子アダプター（ATA）になります。ルーターに埋め込まれた関数）：
1. combined router and NTE.
1. ルーターとNTEの組み合わせ。
2. separate router with NTE in bridged mode.
2. ブリッジモードでNTEでルーターを分離します。
3. separate router with NTE (NTE/router does PPPoE or DHCP to WAN, router provides DHCP server for hosts in LAN; double NAT).
3. NTE（NTE/RouterがPPPOEまたはDHCPをWANに分離し、RouterはLAN; Double NATのホストにDHCPサーバーを提供します）。
The majority of fixed-access broadband customers use a router. The placement of the VoIP client is mentioned to describe what sorts of hosts may need to be able to request location information. Soft clients on PCs are frequently not launched until long after bootstrapping is complete, and are not able to control any options that may be specified during bootstrapping. They also cannot control whether a VPN client is running on the end host.
固定アクセスブロードバンドの顧客の大部分はルーターを使用しています。VoIPクライアントの配置は、位置情報をリクエストできるようにホストの種類を説明するために言及されています。PCのソフトクライアントは、ブートストラップが完了してからずっと後まで起動されず、ブートストラップ中に指定される可能性のあるオプションを制御することができません。また、VPNクライアントがエンドホストで実行されているかどうかを制御することもできません。
One example of a moving network is a WiMAX-fixed wireless scenario. This also applies to "pre-WiMAX" and "WiMAX-like" fixed wireless networks. In implementations intended to provide broadband service to a home or other stationary location, the customer-side antenna/NTE tends to be rather small and portable. The LAN-side output of this device is an Ethernet jack, which can be used to feed a PC or a router. The PC or router then uses DHCP or PPPoE to connect to the access network, the same as for wired access networks. Access providers who deploy this technology may use the same core network (including network elements that terminate PPPoE and provide IP addresses) for DSL, fiber to the premises (FTTP), and fixed wireless customers.
移動ネットワークの1つの例は、WIMAX固定ワイヤレスシナリオです。これは、「プレウィマックス」および「ウィマックスのような」固定ワイヤレスネットワークにも適用されます。家庭やその他の静止した場所にブロードバンドサービスを提供することを目的とした実装では、顧客側のアンテナ/NTEはかなり小さくてポータブルである傾向があります。このデバイスのLAN側出力はイーサネットジャックで、PCまたはルーターの供給に使用できます。PCまたはルーターは、DHCPまたはPPPOEを使用して、有線アクセスネットワークと同じようにアクセスネットワークに接続します。このテクノロジーを展開するアクセスプロバイダーは、DSL、Fiber（FTTP）、および固定ワイヤレス顧客の同じコアネットワーク（PPPOEを終了してIPアドレスを提供するネットワーク要素を含む）を使用する場合があります。
Given that the customer antenna is portable and can be battery-powered, it is possible for a user to connect a laptop to it and move within the coverage area of a single base antenna. This coverage area can be many square kilometers in size. In this case, the laptop (and any SIP client running on it) would be completely unaware of their mobility. Only the user and the network are aware of the laptop's mobility.
顧客アンテナがポータブルでバッテリー駆動の可能性があることを考えると、ユーザーはラップトップをそれに接続し、単一のベースアンテナのカバレッジエリア内を移動することができます。このカバレッジエリアは、サイズが数平方キロメートルになる場合があります。この場合、ラップトップ（およびその上で実行されているSIPクライアント）は、モビリティを完全に知らないでしょう。ユーザーとネットワークのみがラップトップのモビリティを認識しています。
Further examples of moving networks (where end devices may not be aware that they are moving) can be found in busses, trains, and airplanes.
移動ネットワークのさらなる例（エンドデバイスが移動していることを認識していない場合があります）は、バス、列車、および飛行機で見つけることができます。
Figure 2 shows an example topology for a moving network.
図2は、移動ネットワークのトポロジの例を示しています。
+--------------------------+
| Wireless |
| Access Network Provider |
| |
| +----------+|
| +-------+ LIS ||
| | | ||
| +---+----+ +----------+|
| | Node | |
| | | |
| +---+----+ |
| | |
+------+-------------------+
| Wireless Interface
|
+------+-------------------+
| | Moving Network |
| +---+----+ |
| | NTE | +--------+ |
| | +---+ Host | |
| +-+-----++ | B | |
| | \ +--------+ |
| | \ |
|+---+----+ \ +---+----+ |
|| Host | \ | Host | |
|| A | \+ B | |
|+--------+ +--------+ |
+--------------------------+
Figure 2: Moving Network
図2：移動ネットワーク
Figure 3 shows a wireless access network where a moving host obtains location information or references to location information from the LIS. The access equipment uses, in many cases, link-layer devices. Figure 3 represents a hotspot network found, for example, in hotels, airports, and coffee shops. For editorial reasons we only describe a single access point and do not depict how the LIS obtains location information since this is very deployment specific.
図3は、移動ホストが位置情報またはLISからの位置情報への参照を取得するワイヤレスアクセスネットワークを示しています。アクセス機器は、多くの場合、リンク層デバイスを使用します。図3は、たとえばホテル、空港、コーヒーショップで見つかったホットスポットネットワークを表しています。編集上の理由から、私たちは単一のアクセスポイントのみを記述し、LISが非常に展開固有であるため、LISがどのように位置情報を取得するかを描写していません。
+--------------------------+
| Access Network Provider |
| |
| +----------+|
| +-------| LIS ||
| | | ||
| +--------+ +----------+|
| | Access | |
| | Point | |
| +--------+ |
| | |
+------+-------------------+
|
+------+
| Host |
+------+
Figure 3: Wireless Access Scenario
図3：ワイヤレスアクセスシナリオ
Note that this section lists mechanisms that were discussed in the GEOPRIV Layer 7 Location Configuration Protocol design team. They are included to show challenges in the problem space and are listed for completeness reasons. They do not in any way mean that there is consensus about any of the mechanisms or that the IETF recommends any of the procedures described in this section.
このセクションには、Geopriv Layer 7 Location Configuration Protocol Design Teamで説明されたメカニズムがリストされていることに注意してください。問題の分野で課題を示すために含まれており、完全な理由でリストされています。それらは、メカニズムのいずれかについてコンセンサスがあること、またはIETFがこのセクションで説明した手順を推奨することを決して意味しません。
When a device wants to retrieve location information from the LIS, it first needs to discover it. Based on the problem statement of determining the location of the device, which is known best by entities close to the device itself, we assume that the LIS is located in the local subnet or in the access network. Several procedures have been investigated that aim to discover the LIS in such an access network.
デバイスがLISから位置情報を取得したい場合、最初に発見する必要があります。デバイス自体に近いエンティティで最もよく知られているデバイスの位置を決定するという問題のステートメントに基づいて、LISはローカルサブネットまたはアクセスネットワークにあると仮定します。このようなアクセスネットワークでLISを発見することを目的としたいくつかの手順が調査されています。
DHCP-based Discovery:
DHCPベースの発見：
In some environments, the Dynamic Host Configuration Protocol (DHCP) might be a good choice for discovering the fully-qualified domain name (FQDN) or the IP address of the LIS. In environments where DHCP can be used, it is also possible to use the already defined location extensions. In environments with legacy devices, such as the one shown in Section 3.1, a DHCP-based discovery solution may not be possible.
一部の環境では、動的ホスト構成プロトコル（DHCP）は、完全に適格なドメイン名（FQDN）またはLISのIPアドレスを発見するのに適した選択かもしれません。DHCPを使用できる環境では、既に定義されているロケーション拡張機能を使用することもできます。セクション3.1に示されているようなレガシーデバイスを備えた環境では、DHCPベースのディスカバリーソリューションは不可能です。
DNS-based Discovery:
DNSベースの発見：
Before a Domain Name System (DNS) lookup can be started, it is necessary to learn the domain name of the access network that runs an LIS. Several ways to learn the domain name exist. For example, the end host obtains its own public IP address via Simple Traversal of the UDP Protocol through NAT (STUN) [RFC5389], and performs a reverse DNS lookup (assuming the data is provisioned into the DNS). Then, the DNS Service (SRV) record or the DNS Naming Authority Pointer (NAPTR) record for that domain is retrieved. A more detailed description of this approach can be found in [LIS-DISC].
ドメイン名システム（DNS）ルックアップを開始する前に、LISを実行するアクセスネットワークのドメイン名を学習する必要があります。ドメイン名を学習するいくつかの方法が存在します。たとえば、ENDホストは、NAT（STUN）[RFC5389]を介したUDPプロトコルの単純なトラバーサルを介して独自のパブリックIPアドレスを取得し、逆DNSルックアップを実行します（データがDNSにプロビジョニングされていると仮定）。次に、そのドメインのDNSサービス（SRV）レコードまたはDNSネーミングオーソリティポインター（NAPTR）レコードが取得されます。このアプローチのより詳細な説明は、[lis-disc]にあります。
Redirect Rule:
ルールのリダイレクト：
A redirect rule at an entity in the access network could be used to redirect the L7 LCP signaling messages (destined to a specific port) to the LIS. The device could then discover the LIS by sending a packet with a specific (registered) port number to almost any address as long as the destination IP address does not target an entity in the local network. The packet would be redirected to the respective LIS being configured. The same procedure is used by captive portals whereby any HTTP traffic is intercepted and redirected.
アクセスネットワーク内のエンティティでのリダイレクトルールを使用して、L7 LCPシグナリングメッセージ（特定のポートに運命づけられている）をLISにリダイレクトできます。宛先IPアドレスがローカルネットワーク内のエンティティをターゲットにしていない限り、特定の（登録された）ポート番号を持つパケットをほぼすべてのアドレスに送信することにより、デバイスはLISを発見できます。パケットは、構成されているそれぞれのLISにリダイレクトされます。同じ手順は、HTTPトラフィックが傍受され、リダイレクトされるキャプティブポータルで使用されます。
To some extent, this approach is similar to packets that are marked with a Router Alert option [RFC2113] and intercepted by entities that understand the specific marking. In the above-mentioned case, however, the marking is provided via a registered port number instead of relying on a Router Alert option.
ある程度、このアプローチは、ルーターアラートオプション[RFC2113]でマークされたパケットに似ており、特定のマークを理解するエンティティによって傍受されます。ただし、上記の場合、マーキングは、ルーターアラートオプションに依存する代わりに、登録されたポート番号を介して提供されます。
This solution approach would require a deep packet inspection capability at an entity in the access provider's networks that scans for the occurrence of particular destination port numbers.
このソリューションアプローチでは、特定の宛先ポート番号の発生をスキャンするアクセスプロバイダーのネットワークのエンティティでの深いパケット検査機能が必要です。
Multicast Query:
マルチキャストクエリ：
A device could also discover an LIS by sending a DNS query to a well-known address. An example of such a mechanism is multicast DNS (see [RFC4795] and [mDNS]). Unfortunately, these mechanisms only work on the local link.
デバイスは、よく知られているアドレスにDNSクエリを送信することにより、LISを発見することもできます。このようなメカニズムの例は、マルチキャストDNSです（[RFC4795]および[MDNS]を参照）。残念ながら、これらのメカニズムはローカルリンクでのみ機能します。
Anycast:
Anycast：
With this solution, an anycast address is defined (for IPv4 and IPv6) in the style of [RFC3068] that allows the device to route discovery packets to the nearest LIS. Note that this procedure would be used purely for discovery and is therefore similar to the local Teredo server discovery approach outlined in Section 4.2 of [TEREDO-SEL].
このソリューションを使用すると、[RFC3068]のスタイルでAnycastアドレス（IPv4およびIPv6の場合）が定義されているため、デバイスはディスカバリーパケットを最も近いLISにルーティングできます。この手順は純粋に発見に使用されるため、[Teredo-SEL]のセクション4.2で概説されているローカルテレドサーバー発見アプローチに似ていることに注意してください。
The LIS discovery procedure raises deployment and security issues. The access network needs to be designed to prevent man-in-the-middle adversaries from presenting themselves as an LIS to devices. When a device discovers an LIS, it needs to ensure (and be able to ensure) that the discovered entity is indeed an authorized LIS.
LIS発見手順により、展開とセキュリティの問題が発生します。アクセスネットワークは、中間の敵が自分自身をデバイスに提示することを防ぐために設計する必要があります。デバイスがLISを発見した場合、発見されたエンティティが実際に認定されたLIであることを確実に保証する必要があります。
Note that this section lists mechanisms that were discussed in the GEOPRIV Layer 7 Location Configuration Protocol design team. They are included to show challenges in the problem space and are listed for completeness reasons. They do not in any way mean that there is consensus about any of the mechanisms or that the IETF recommends any of the procedures described in this section.
このセクションには、Geopriv Layer 7 Location Configuration Protocol Design Teamで説明されたメカニズムがリストされていることに注意してください。問題の分野で課題を示すために含まれており、完全な理由でリストされています。それらは、メカニズムのいずれかについてコンセンサスがあること、またはIETFがこのセクションで説明した手順を推奨することを決して意味しません。
The LIS returns location information to the device when it receives a request. Some form of identifier is therefore needed to allow the LIS to retrieve the device's current location, or a good approximation, from a database.
LISは、リクエストを受信したときに位置情報をデバイスに返します。したがって、LISがデータベースからデバイスの現在の場所、または適切な近似を取得できるようにするには、何らかの形の識別子が必要です。
The chosen identifier needs to have the following properties:
選択した識別子には、次のプロパティが必要です。
Ability for Device to learn or know the identifier:
識別子を学習または把握するデバイスの能力：
The device MUST know or MUST be able to learn of the identifier (explicitly or implicitly) in order to send it to the LIS. Implicitly refers to the situation where a device along the path between the device and the LIS modifies the identifier, as it is done by a NAT when an IP address based identifier is used.
デバイスは、LISに送信するために（明示的または暗黙的に）識別子を知っているか、学習できる必要があります。暗黙的に、IPアドレスベースの識別子が使用されている場合にNATによって行われるように、デバイスとLISの間のパスに沿ったデバイスが識別子を変更する状況を指します。
Ability to use the identifier for location determination:
位置決定に識別子を使用する能力：
The LIS MUST be able to use the identifier (directly or indirectly) for location determination. Indirectly refers to the case where the LIS uses other identifiers internally for location determination, in addition to the one provided by the device.
LISは、位置決定のために識別子（直接的または間接的に）を使用できる必要があります。間接的に、LISがデバイスが提供するものに加えて、LISが位置決定に内部的に他の識別子を使用する場合を指します。
Security properties of the identifier:
識別子のセキュリティプロパティ：
Misuse needs to be minimized whereby an off-path adversary MUST NOT be able to obtain location information of other devices. An on-path adversary in the same subnet SHOULD NOT be able to spoof the identifier of another device in the same subnet.
誤用を最小限に抑える必要があります。これにより、オフパスの敵が他のデバイスの位置情報を取得できない必要があります。同じサブネットのパス上の敵は、同じサブネット内の別のデバイスの識別子を押し付けることができないはずです。
The following list discusses frequently mentioned identifiers and their properties:
次のリストでは、頻繁に言及された識別子とそのプロパティについて説明します。
Media Access Control (MAC) Address:
メディアアクセス制御（MAC）アドレス：
The MAC address is known to the device itself, but not carried beyond a single IP hop and therefore not accessible to the LIS in most deployment environments (unless carried in the L7 LCP itself).
MACアドレスはデバイス自体に知られていますが、単一のIPホップを超えて運ばれていないため、ほとんどの展開環境ではLISにアクセスできません（L7 LCP自体で運ばない限り）。
Asynchronous Transfer Mode (ATM) Virtual Path Identifier / Virtual Circuit Identifier (VPI/VCI):
非同期転送モード（ATM）仮想パス識別子 /仮想回路識別子（VPI / VCI）：
The VCI/VPI is generally only seen by the DSL modem. Almost all routers in the United States use 1 of 2 VPI/VCI value pairs: 0/35 and 8/35. This VC is terminated at the digital subscriber line access multiplexer (DSLAM), which uses a different VPI/VCI (per end customer) to connect to the ATM switch. Only the network provider is able to map VPI/VCI values through its network. With the arrival of Very high rate Digital Subscriber Line (VDSL), ATM will slowly be phased out in favor of Ethernet.
VCI/VPIは通常、DSLモデムのみで見られます。米国のほぼすべてのルーターは、2つのVPI/VCI値ペアのうち1つを使用しています：0/35および8/35。このVCは、Digital Subscriber Line Access Multiplexer（DSLAM）で終了します。これは、異なるVPI/VCI（エンドカスタマーごと）を使用してATMスイッチに接続します。ネットワークプロバイダーのみが、ネットワークを介してVPI/VCI値をマッピングできます。非常に高いレートのデジタルサブスクライバーライン（VDSL）が到着すると、ATMはゆっくりとイーサネットを支持して段階的に段階的に廃止されます。
Ethernet Switch (Bridge)/Port Number:
イーサネットスイッチ（ブリッジ）/ポート番号：
This identifier is available only in certain networks, such as enterprise networks, typically available via the IEEE 802.1AB protocol [802.1AB] or proprietary protocols like the Cisco Discovery Protocol (CDP) [CDP].
この識別子は、通常、IEEE 802.1ABプロトコル[802.1AB]またはCisco Discovery Protocol（CDP）[CDP]などの独自のプロトコルを介して利用可能なエンタープライズネットワークなど、特定のネットワークでのみ利用できます。
Cell ID:
セルID：
This identifier is available in cellular data networks and the cell ID may not be visible to the device.
この識別子はセルラーデータネットワークで利用でき、セルIDがデバイスに表示されない場合があります。
Host Identifier:
ホスト識別子：
The Host Identifier introduced by the Host Identity Protocol (HIP) [RFC5201] allows identification of a particular host. Unfortunately, the network can only use this identifier for location determination if the operator already stores a mapping of host identities to location information. Furthermore, there is a deployment problem since the host identities are not used in today's networks.
ホストIDプロトコル（HIP）[RFC5201]によって導入されたホスト識別子は、特定のホストの識別を可能にします。残念ながら、ネットワークは、オペレーターが既にホストIDのマッピングを位置情報に保存している場合にのみ、位置決定にこの識別子を使用できます。さらに、ホストのアイデンティティは今日のネットワークでは使用されていないため、展開の問題があります。
Cryptographically Generated Address (CGA):
暗号化されたアドレス（CGA）：
The concept of a Cryptographically Generated Address (CGA) was introduced by [RFC3972]. The basic idea is to put the truncated hash of a public key into the interface identifier part of an IPv6 address. In addition to the properties of an IP address, it allows a proof of ownership. Hence, a return routability check can be omitted. It is only available for IPv6 addresses.
暗号化されたアドレス（CGA）の概念は、[RFC3972]によって導入されました。基本的なアイデアは、公開キーの切り捨てられたハッシュをIPv6アドレスのインターフェイス識別子部分に入れることです。IPアドレスのプロパティに加えて、所有権の証明が可能になります。したがって、返品ルー上のチェックを省略できます。IPv6アドレスでのみ使用できます。
Network Access Identifiers:
ネットワークアクセス識別子：
A Network Access Identifier [RFC4282] is used during the network access authentication procedure, for example, in RADIUS [RFC2865] and Diameter [RFC3588]. In DSL networks, the user credentials are, in many cases, only known by the home router and not configured at the device itself. To the network, the authenticated user identity is only available if a network access authentication procedure is executed. In case of roaming, the user's identity might not be available to the access network since security protocols might offer user identity confidentiality and thereby hide the real identity of the user allowing the access network to only see a pseudonym or a randomized string.
ネットワークアクセス識別子[RFC4282]は、たとえばRADIUS [RFC2865]および直径[RFC3588]など、ネットワークアクセス認証手順で使用されます。DSLネットワークでは、ユーザーの資格情報は、多くの場合、ホームルーターでのみ知られており、デバイス自体で構成されていません。ネットワークに対して、認証されたユーザーIDは、ネットワークアクセス認証手順が実行された場合にのみ利用可能です。ローミングの場合、セキュリティプロトコルはユーザーIDの機密性を提供し、ユーザーの実際のIDを隠すために、ユーザーのIDはアクセスネットワークで利用できない可能性があります。
Unique Client Identifier
一意のクライアント識別子
The Broadband Forum has defined that all devices that expect to be managed by the TR-069 interface, see [TR069], have to be able to generate an identifier that uniquely identifies the device. It also has a requirement that routers that use DHCP to the WAN use RFC 4361 [RFC4361] to provide the DHCP server with a unique client identifier. This identifier is, however, not visible to the device when legacy NTE devices are used.
ブロードバンドフォーラムは、TR-069インターフェイスによって管理されると予想されるすべてのデバイス[TR069]を参照して、デバイスを一意に識別する識別子を生成できる必要があることを定義しています。また、DHCPをWANに使用するルーターがRFC 4361 [RFC4361]を使用してDHCPサーバーに一意のクライアント識別子を提供する必要があります。ただし、この識別子は、レガシーNTEデバイスを使用する場合、デバイスに表示されません。
IP Address:
IPアドレス：
The device's IP address may be used for location determination. This IP address is not visible to the LIS if the device is behind one or multiple NATs. This may not be a problem since the location of a device that is located behind a NAT cannot be determined by the access network. The LIS would in this case only see the public IP address of the NAT binding allocated by the NAT, which is the expected behavior. The property of the IP address for a return routability check is attractive to return location information only to the address that submitted the request. If an adversary wants to learn the location of a device (as identified by a particular IP address), then it does not see the response message (unless it is on the subnetwork or at a router along the path towards the LIS).
デバイスのIPアドレスは、場所の決定に使用できます。このIPアドレスは、デバイスが1つまたは複数のNATの背後にある場合、LISに表示されません。NATの背後にあるデバイスの場所は、アクセスネットワークによって決定できないため、これは問題ではない可能性があります。この場合、LISは、予想される動作であるNATによって割り当てられたNAT結合のパブリックIPアドレスのみを表示します。返品ルー上のチェックのIPアドレスのプロパティは、リクエストを提出したアドレスにのみ位置情報を返すのに魅力的です。敵が（特定のIPアドレスで識別されているように）デバイスの場所を学習したい場合、応答メッセージは表示されません（サブネットワーク上またはLISに向かうパスに沿ったルーターにある場合を除く）。
On a shared medium, an adversary could ask for location information of another device. The adversary would be able to see the response message since it is sniffing on the shared medium unless security mechanisms, such as link-layer encryption, are in place. With a network deployment as shown in Section 3.1 with multiple devices in the Customer Premises being behind a NAT, the LIS is unable to differentiate the individual devices. For WLAN deployments as found in hotels, as shown in Section 3.3, it is possible for an adversary to eavesdrop data traffic and subsequently to spoof the IP address in a query to the LIS to learn more detailed location information (e.g., specific room numbers). Such an attack might, for example, compromise the privacy of hotel guests.
共有媒体では、敵が別のデバイスの位置情報を求めることができます。敵は、リンク層暗号化などのセキュリティメカニズムが整っていない限り、共有媒体で嗅ぎ取っているため、応答メッセージを見ることができます。セクション3.1に示されているように、ネットワークの展開がNATの背後にある顧客施設の複数のデバイスを含むため、LISは個々のデバイスを区別できません。セクション3.3に示すように、ホテルにあるWLANの展開の場合、敵がデータトラフィックを盗聴し、その後、LISにクエリでIPアドレスをスプーフィングして、より詳細な位置情報を学習することが可能です（例えば、特定の部屋番号）。このような攻撃は、たとえば、ホテルのゲストのプライバシーを損なう可能性があります。
The following requirements and assumptions have been identified:
次の要件と仮定が特定されています。
Requirement L7-1: Identifier Choice
要件L7-1：識別子の選択
The L7 LCP MUST be able to carry different identifiers or MUST define an identifier that is mandatory to implement. Regarding the latter aspect, such an identifier is only appropriate if it is from the same realm as the one for which the location information service maintains identifier-to-location mapping.
L7 LCPは、異なる識別子を運ぶことができる必要があります。または、実装することが必須の識別子を定義する必要があります。後者の側面に関しては、そのような識別子は、位置情報サービスが識別子からロケーションマッピングを維持しているものと同じ領域からの場合にのみ適切です。
Requirement L7-2: Mobility Support
要件L7-2：モビリティサポート
The L7 LCP MUST support a broad range of mobility from devices that can only move between reboots, to devices that can change attachment points with the impact that their IP address is changed, to devices that do not change their IP address while roaming, to devices that continuously move by being attached to the same network attachment point.
L7 LCPは、再起動間でのみ移動できるデバイスから、IPアドレスが変更される影響とともに添付ポイントを変更できるデバイス、ローミング中のIPアドレスを変更しないデバイス、デバイスに幅広いモビリティをサポートする必要があります。それは、同じネットワークアタッチメントポイントに接続されることによって継続的に移動します。
Requirement L7-3: ASP and Access Network Provider Relationship
要件L7-3：ASPおよびアクセスネットワークプロバイダーの関係
The design of the L7 LCP MUST NOT assume that a business or trust relationship between the Application Service Provider (ASP) and the Access Network Provider. Requirements for resolving a reference to location information are not discussed in this document.
L7 LCPの設計は、アプリケーションサービスプロバイダー（ASP）とアクセスネットワークプロバイダーとの間のビジネスまたは信頼関係が想定してはなりません。位置情報への参照を解決するための要件については、このドキュメントでは説明されていません。
Requirement L7-4: Layer 2 and Layer 3 Provider Relationship
要件L7-4：レイヤー2とレイヤー3プロバイダー関係
The design of the L7 LCP MUST assume that there is a trust and business relationship between the L2 and the L3 provider. The L3 provider operates the LIS that the device queries. It, in turn, needs to obtain location information from the L2 provider since this one is closest to the device. If the L2 and L3 provider for the same device are different entities, they cooperate for the purposes needed to determine locations.
L7 LCPの設計は、L2とL3プロバイダーの間に信頼とビジネス関係があると想定する必要があります。L3プロバイダーは、デバイスがクエリするLISを操作します。次に、これはデバイスに最も近いため、L2プロバイダーから位置情報を取得する必要があります。同じデバイスのL2およびL3プロバイダーが異なるエンティティである場合、場所を決定するために必要な目的のために協力します。
Requirement L7-5: Legacy Device Considerations
要件L7-5：レガシーデバイスの考慮事項
The design of the L7 LCP MUST consider legacy devices, such as residential NAT devices and NTEs in a DSL environment, that cannot be upgraded to support additional protocols, for example, to pass additional information towards the device.
L7 LCPの設計では、DSL環境の住宅NATデバイスやNTEなどのレガシーデバイスを考慮する必要があります。これは、追加のプロトコルをサポートするためにアップグレードすることはできません。たとえば、デバイスに追加情報を渡すことができます。
Requirement L7-6: Virtual Private Network (VPN) Awareness
要件L7-6：仮想プライベートネットワーク（VPN）認識
The design of the L7 LCP MUST assume that at least one end of a VPN is aware of the VPN functionality. In an enterprise scenario, the enterprise side will provide the LIS used by the device and can thereby detect whether the LIS request was initiated through a VPN tunnel.
L7 LCPの設計は、VPNの少なくとも片端がVPN機能を認識していると想定する必要があります。エンタープライズシナリオでは、エンタープライズ側はデバイスで使用されるLISを提供し、それにより、VPNトンネルを介してLIS要求が開始されたかどうかを検出できます。
Requirement L7-7: Network Access Authentication
要件L7-7：ネットワークアクセス認証
The design of the L7 LCP MUST NOT assume that prior network access authentication.
L7 LCPの設計は、以前のネットワークアクセス認証を想定してはなりません。
Requirement L7-8: Network Topology Unawareness
要件L7-8：ネットワークトポロジは認識されていません
The design of the L7 LCP MUST NOT assume that devices are aware of the access network topology. Devices are, however, able to determine their public IP address(es) via mechanisms, such as Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) [RFC5389] or Next Steps in Signaling (NSIS) NAT/Firewall NSIS Signaling Layer Protocol (NSLP) [NSLP].
L7 LCPの設計は、デバイスがアクセスネットワークトポロジを認識していると仮定してはなりません。ただし、デバイスは、ネットワークアドレス翻訳者（NAT）（STUN）[RFC5389]を介してユーザーデータグラムプロトコル（UDP）の単純なトラバーサルなど、メカニズムを介してパブリックIPアドレスを決定できます。NAT/ファイアウォールNSISシグナリングレイヤープロトコル（NSLP）[NSLP]。
Requirement L7-9: Discovery Mechanism
要件L7-9：発見メカニズム
The L7 LCP MUST define a mandatory-to-implement LIS discovery mechanism.
L7 LCPは、必須のリス発見メカニズムを定義する必要があります。
Requirement L7-10: PIDF-LO Creation
要件L7-10：PIDF-LO作成
When an LIS creates a Presence Information Data Format (PIDF) Location Object (LO) [RFC4119], then it MUST put the <geopriv> element into the <device> element of the presence document (see [RFC4479]). This ensures that the resulting PIDF-LO document, which is subsequently distributed to other entities, conforms to the rules outlined in [RFC5491].
LISが存在情報データ形式（PIDF）ロケーションオブジェクト（LO）[RFC4119]を作成する場合、<geopriv>要素を存在ドキュメントの<device>要素に配置する必要があります（[RFC4479]を参照）。これにより、結果のPIDF-LOドキュメントは、その後他のエンティティに配布されることが保証され、[RFC5491]で概説されているルールに準拠しています。
By using a Geolocation L7 Location Configuration Protocol, the device (and a human user of such a device, if applicable) exposes themselves to a privacy risk whereby an unauthorized entity receives location information. Providing confidentiality protected location to the requestor depends on the success of four steps:
Geolocation L7 Location Configuration Protocolを使用することにより、デバイス（およびそのようなデバイスの人間ユーザー、該当する場合）は、不正なエンティティが位置情報を受信するプライバシーリスクにさらされます。Requestorに保護された場所を守備保護する場所を提供することは、4つのステップの成功に依存します。
1. The client MUST have a means to discover a LIS.
1. クライアントには、LISを発見する手段が必要です。
2. The client MUST authenticate the discovered LIS.
2. クライアントは、発見されたLISを認証する必要があります。
3. The LIS MUST be able to determine location and return it to the authorized entity.
3. LISは、場所を決定し、認定エンティティに戻すことができなければなりません。
4. The LIS MUST securely exchange messages without intermediaries eavesdropping or tampering with them.
4. LISは、仲介者が盗聴したり改ざんしたりすることなく、メッセージを安全に交換する必要があります。
This document contains various security-related requirements throughout the document addressing the above-mentioned steps. For a broader security discussion of the overall geolocation privacy architecture, the reader is referred to [GEOPRIV-ARCH].
このドキュメントには、上記の手順に対処するドキュメント全体のさまざまなセキュリティ関連の要件が含まれています。全体的なジオロケーションプライバシーアーキテクチャに関するより広範なセキュリティの議論のために、読者は[Geopriv-arch]と呼ばれます。
This contribution is a joint effort of the GEOPRIV Layer 7 Location Configuration Requirements Design Team of the IETF GEOPRIV Working Group. The contributors include Henning Schulzrinne, Barbara Stark, Marc Linsner, Andrew Newton, James Winterbottom, Martin Thomson, Rohan Mahy, Brian Rosen, Jon Peterson, and Hannes Tschofenig.
この貢献は、IETF GEOPRIVワーキンググループのJOOPRIVレイヤー7位置構成要件デザインチームの共同の取り組みです。貢献者には、ヘニング・シュルツリン、バーバラ・スターク、マーク・リンナー、アンドリュー・ニュートン、ジェームズ・ウィンターボトム、マーティン・トムソン、ロハン・マヒ、ブライアン・ローゼン、ジョン・ピーターソン、ハネス・ツェコフェニグが含まれます。
We would like to thank the GEOPRIV Working Group Chairs, Andy Newton, Randy Gellens, and Allison Mankin, for creating the design team. Furthermore, we would like thank Andy Newton for his support during the design team mailing list, for setting up Jabber chat conferences, and for participating in the phone conference discussions.
デザインチームを作ってくれたGeoprivワーキンググループの椅子、アンディニュートン、ランディゲレンズ、アリソンマンキンに感謝します。さらに、デザインチームのメーリングリストでのサポート、Jabberチャット会議の設定、電話会議の議論への参加について、Andy Newtonに感謝します。
The design team members can be reached at:
デザインチームのメンバーには、次のように連絡できます。
Marc Linsner: mlinsner@cisco.com
Marc Linsner：mlinsner@cisco.com
Rohan Mahy: rohan@ekabal.com
Rohan Mahy：rohan@ekabal.com
Andrew Newton: andy@hxr.us
アンドリュー・ニュートン：andy@hxr.us
Jon Peterson: jon.peterson@neustar.biz
ジョン・ピーターソン：jon.peterson@neustar.biz
Brian Rosen: br@brianrosen.net
ブライアンローゼン：br@brianrosen.net
Henning Schulzrinne: hgs@cs.columbia.edu
Henning Schulzrinne：hgs@cs.columbia.edu
Barbara Stark: Barbara.Stark@bellsouth.com
Barbara Stark：barbara.stark@bellsouth.com
Martin Thomson: Martin.Thomson@andrew.com
Martin Thomson：Martin.Thomson@Andrew.com
Hannes Tschofenig: Hannes.Tschofenig@nsn.com
hannes tschofenig：hannes.tschofenig@nsn.com
James Winterbottom: James.Winterbottom@andrew.com
James Winterbottom：James.winterbottom@andrew.com
We would also like to thank Murugaraj Shanmugam, Ted Hardie, Martin Dawson, Richard Barnes, James Winterbottom, Tom Taylor, Otmar Lendl, Marc Linsner, Brian Rosen, Roger Marshall, Guy Caron, Doug Stuard, Eric Arolick, Dan Romascanu, Jerome Grenier, Martin Thomson, Barbara Stark, Michael Haberler, and Mary Barnes for their WGLC review comments.
また、Murugaraj Shanmugam、Ted Hardie、Martin Dawson、Richard Barnes、James Winterbottom、Tom Taylor、Otmar Lendl、Marc Linsner、Brian Rosen、Roger Marshall、Guy Caron、Doug Stuard、Eric Arolick、Dan Romascanu、Jerom、Martin Thomson、Barbara Stark、Michael Haberler、およびMary BarnesのWGLCレビューコメントについて。
The authors would like to thank NENA for their work on [NENA] as it helped to provide some of the initial thinking.
著者は、最初の思考のいくつかを提供するのに役立ったので、[ネナ]の仕事についてネナに感謝したいと思います。
The authors would also like to thank Cullen Jennings for his feedback as part of the IESG processing. Additionally, we would like to thank Alexey Melnikov, Dan Romascanu, and Robert Sparks.
著者はまた、IESG処理の一部としてのフィードバックについてCullen Jenningsに感謝したいと思います。さらに、Alexey Melnikov、Dan Romascanu、およびRobert Sparksに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.
[RFC5012] Schulzrinne、H。およびR. Marshall、「インターネットテクノロジーによる緊急コンテキスト解決の要件」、RFC 5012、2008年1月。
[802.1AB] "IEEE 802.1AB-2005 IEEE Standard for Local and Metropolitan Area Networks Station and Media Access Control Connectivity Discovery", May 2005, <http:// standards.ieee.org/getieee802/download/ 802.1AB-2005.pdf>.
[802.1ab]「IEEE 802.1AB-2005ローカルおよびメトロポリタンエリアネットワークステーションおよびメディアアクセス制御接続の発見のIEEE標準」、<http：// stardand.ieee.org/getieee802/download/ 802.1AB-2005。pdf>。
[CDP] Wikipedia, "Cisco Discovery Protocol (CDP)", <http:// en.wikipedia.org/wiki/Cisco_Discovery_Protocol>.
[CDP] Wikipedia、「Cisco Discovery Protocol（CDP）」、<http：// en.wikipedia.org/wiki/cisco_discovery_protocol>。
[GEOPRIV-ARCH] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", Work in Progress, October 2009.
[Geopriv-Arch] Barnes、R.、Lepinski、M.、Cooper、A.、Morris、J.、Tschofenig、H。、およびH. Schulzrinne、「インターネットアプリケーションの場所と場所のプライバシーのアーキテクチャ」、進捗、2009年10月。
[LBYR-REQS] Marshall, R., Ed., "Requirements for a Location-by-Reference Mechanism", Work in Progress, November 2009.
[lbyr-reqs] Marshall、R.、ed。、「場所ごとのメカニズムの要件」、2009年11月、進行中の作業。
[LIS-DISC] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", Work in Progress, February 2010.
[LIS-DISC] Thomson、M。およびJ. Winterbottom、「Local Location Information Server（LIS）の発見」、2010年2月の作業進行中。
[LIS2LIS] Winterbottom, J. and S. Norreys, "LIS to LIS Protocol Requirements", Work in Progress, November 2007.
[Lis2lis] Winterbottom、J。およびS. Norreys、「Lis to Lis Protocol Recomission」、2007年11月、進行中の作業。
[NENA] "NENA 08-505, Issue 1, 2006 (December 21, 2006), NENA Recommended Method(s) for Location Determination to Support IP-Based Emergency Services - Technical Information Document (TID)", December 2006, <http:// www.nena.org/sites/default/files/ 08-505_20061221.pdf>.
[Nena] "Nena 08-505、Issue 1、2006（2006年12月21日）、NenaはIPベースの緊急サービスをサポートするための場所を決定するための方法を推奨しました - 技術情報ドキュメント（TID）、2006年12月、<http：// www.nena.org/sites/default/files/ 08-505_20061221.pdf>。
[NSLP] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Work in Progress, February 2010.
[NSLP] Stiemerling、M.、Tschofenig、H.、Aoun、C。、およびE. Davies、「Nat/Firewall NSIS Signaling Layer Protocol（NSLP）」、Work in Progress、2010年2月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113] Katz、D。、「IPルーターアラートオプション」、RFC 2113、1997年2月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068] Huitema、C。、「6to4リレールーターのAnycast Prefix」、RFC 3068、2001年6月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]オーラ、T。、「暗号化されたアドレス（CGA）」、RFC 3972、2005年3月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119] Peterson、J。、「存在ベースのGeoprivロケーションオブジェクト形式」、RFC 4119、2005年12月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J。、およびP. Eronen、「ネットワークアクセス識別子」、RFC 4282、2005年12月。
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, February 2006.
[RFC4361] Lemon、T。およびB. Sommerfeld、「動的ホスト構成プロトコルバージョン4（DHCPV4）のノード固有のクライアント識別子」、RFC 4361、2006年2月。
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[RFC4479] Rosenberg、J。、「存在のためのデータモデル」、RFC 4479、2006年7月。
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, January 2007.
[RFC4795] Aboba、B.、Thaler、D。、およびL. Esibov、「Link-Local Multicast Name Resolution（LLMNR）」、RFC 4795、2007年1月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201] Moskowitz、R.、Nikander、P.、Jokela、P。、およびT. Henderson、「Host Identity Protocol」、RFC 5201、2008年4月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NATのセッショントラバーサルユーティリティ（STUN）」、RFC 5389、2008年10月。
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.
[RFC5491] Winterbottom、J.、Thomson、M。、およびH. Tschofenig、「Geopriv存在情報データ形式の場所オブジェクト（PIDF-LO）使用法の明確化、考慮事項、および推奨事項」、RFC 5491、2009年3月。
[TEREDO-SEL] Ward, N., "Teredo Server Selection", Work in Progress, July 2007.
[Teredo-Sel] Ward、N。、「Teredo Server Selection」、2007年7月、進行中の作業。
[TR069] "TR-069, CPE WAN Management Protocol v1.1, Version: Issue 1 Amendment 2", December 2007, <http:// www.broadband-forum.org/technical/download/ TR-069_Amendment-2.pdf>.
[TR069] "TR-069、CPE WAN管理プロトコルV1.1、バージョン：問題1修正2"、2007年12月、<http：// www.broadband-forum.org/technical/download/ TR-069_AMENDMENT-2。pdf>。
[mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", Work in Progress, September 2009.
[MDNS] Cheshire、S。およびM. Krochmal、「マルチキャストDNS」、2009年9月、進行中の作業。
Authors' Addresses
著者のアドレス
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
ヘニングシュルツリンコロンビア大学コンピュータサイエンス学科450コンピューターサイエンスビル、ニューヨーク州ニューヨーク10027米国
Phone: +1 212 939 7004
EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu