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
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）から、エンドホストは、値または参照することにより、位置情報を取得することを可能にすることを目的とします。取得した位置情報は、異なるプロトコル及び様々な目的のために使用することができます。例えば、ロケーション・ツー・サービス翻訳（LOST）プロトコルへの入力として使用することができ、または他のエンティティにセッション開始プロトコル（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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5687.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
2. 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それは専用ノードから（又はLbyV「値によって場所」と呼ばれる）自身の位置を取得するためにデバイスによって使用され、位置情報サーバー（LIS）と呼ばれます。
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（Uniform Resource Identifier）、HTTP / HTTPS URI、又は他のURIとして、サブスクリプションURIの形をとることができます。 LbyRを取得するタスクに関連する要件を別の文書に記載されている、[LBYR-REQS]を参照。
The need for these two functions can be derived from the scenarios presented in Section 3.
これら二つの機能の必要性は、第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.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" RFC 2119 [RFC2119]に記載されているように、特に明記しない限り、これらの単語がGEOPRIVレイヤ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.
用語ロケーション情報サーバ（LIS）は、デバイスの位置を決定し、ターゲットへのロケーション構成プロトコル（LCP）を介してその位置情報を、それへの参照、またはその両方を提供することができる実体を意味します。
This document also uses terminology from [RFC5012] (such as Internet Access Provider (IAP), Internet Service Provider (ISP), and Application Service Provider (ASP)).
この文書はまた、（例えば、インターネットアクセスプロバイダ（IAP）、インターネットサービスプロバイダ（ISP）として、およびアプリケーションサービスプロバイダ（ASP））[RFC5012]から用語を使用します。
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ツー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
このようなの802.11a / b / gに、802.16eの/ WiMAXのようなO空港、都市、キャンパス無線ネットワーク、
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）ネットワークシナリオを示しています。アクセスネットワークプロバイダは、リンク - およびネットワーク層（ノードとして表される）デバイスと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.
顧客宅内ネットワークは、ほとんどの顧客宅内ネットワーク（CPNS）で使用されるポートアドレス変換（NAPT）と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. 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.
2. with USB-based DSL access or a cable modem access using Point-to-Point Protocol over ATM (PPPoA), PPPoE, or DHCP on PC.
USBベースのDSLアクセスやPC上のポイントツーポイントATMオーバープロトコル（PPPoAの）、PPPoEの、またはDHCPを使用して、ケーブルモデムアクセス2。
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):
少なくとも一つのルータ（DHCPクライアントまたはPPPoE、ルータのDHCPサーバと2つ以上のホストが、ボイスオーバーIP（VoIP）PC上のソフトクライアントすることができ、スタンドアロンのVoIPデバイス、またはアナログターミナルアダプタ（ルータに組み込まれたATA）機能）：
3. separate router with NTE (NTE/router does PPPoE or DHCP to WAN, router provides DHCP server for hosts in LAN; double NAT).
NTE（;ダブルNAT NTE /ルータは、ルータがLAN内のホスト用のDHCPサーバを提供し、WANへのPPPoEやDHCPを行います）3.別のルータ。
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.
移動ネットワークの一例は、WiMAX固定無線シナリオです。これはまた、「前のWiMAX」に適用されると、「WiMAXのような」固定無線ネットワーク。家庭または他の固定場所にブロードバンドサービスを提供することを意図して実装では、顧客側のアンテナ/ NTEはかなり小型でポータブルになる傾向があります。このデバイスのLAN側の出力は、PCまたはルータを供給するために使用することができるイーサネットジャックです。 PCやルータは、有線アクセスネットワークと同じ、アクセスネットワークに接続するには、DHCPまたはPPPoEを使用しています。この技術を導入するアクセスプロバイダがDSL、構内（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は、位置情報を取得する方法を示していません。
+--------------------------+
| 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.
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を実行するアクセスネットワークのドメイン名を学習する必要があります。ドメイン名を知るには、いくつかの方法が存在します。例えば、エンドホストは、NATを介してUDPプロトコル（STUN）の簡易トラバーサル[RFC5389]を介して、自身のパブリック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.
アクセスネットワーク内のエンティティにリダイレクトルールは、LISに（特定のポート宛の）シグナリングメッセージL7 LCPをリダイレクトするために使用することができます。デバイスは、ローカルネットワーク内のエンティティを標的としない宛先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:
エニーキャスト：
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].
この溶液を、エニーキャストアドレスは、最も近いLISへのルート探索パケットにデバイスを可能にする[RFC3068]の様式で（IPv4とIPv6の場合）に定義されます。この手順は、発見のために純粋に使用されることに留意されたい従って[TEREDO-SEL]のセクション4.2に概説ローカルTeredoサーバー発見アプローチに類似しています。
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として自分自身を提示するからなman-in-the-middle敵を防ぐように設計する必要があります。デバイスは、LISを検出すると、それが発見されたエンティティが実際に認可さLISであることを確認してください（と確保することができる）する必要があります。
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.
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が位置決意のために内部の他の識別子を使用した場合のことをいいます。
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.
オフ・パス攻撃者が他のデバイスの位置情報を取得することができないMUSTれる悪用を最小限にする必要があります。同じサブネット内にパス敵は、同じサブネット内の他の装置の識別子を偽造できないようにする必要があり。
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).
（L7 LCP自体で運ばなければ）MACアドレスは、デバイス自体に知られているが、ほとんどの配備環境で、単一のIPホップを越えて行わない、従ってLISがアクセスされていません。
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モデムで見られています。 0/35と8/35：米国のほぼすべてのルータは、1 2のVPI / VCI値のペアを使用します。このVCは、ATMスイッチに接続する（最終顧客ごとに）異なるVPI / VCIを使用してデジタル加入者線アクセスマルチプレクサ（DSLAM）で終端されています。唯一のネットワークプロバイダは、そのネットワークを介して、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]又はシスコ検出プロトコル（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.
ホストアイデンティティプロトコル（HIP）[RFC5201]によって導入されたホスト識別子は、特定のホストの識別を可能にします。オペレータは、既に位置情報にホストアイデンティティのマッピングを格納する場合残念ながら、ネットワークは、位置決定のための識別子を使用することができます。さらに、ホストアイデンティティは、今日のネットワークで使用されていないので、展開問題があります。
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]とDiameter [RFC3588]は、例えば、ネットワークアクセス認証手順の間に使用されます。 DSLネットワークでは、ユーザーの資格情報は、多くの場合、唯一のホームルータで知られており、デバイス自体で構成されていません。ネットワークアクセス認証手順が実行された場合は、ネットワークに、認証されたユーザーの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.
ブロードバンドフォーラムはTR069インタフェースによって管理されることを期待するすべてのデバイスは、デバイスを一意に識別する識別子を生成することができなければならない、[TR069]を参照することを定義しています。また、WANにDHCPを使用するルータは一意のクライアント識別子を持つDHCPサーバーを提供するために、RFC 4361 [RFC4361]を使用する必要性があります。この識別子は、しかし、レガシー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アドレスは、位置決意のために使用することができます。デバイスは、1つまたは複数のNATの背後にある場合、このIPアドレスは、LISには表示されません。 NATの背後に配置されているデバイスの位置は、アクセスネットワークによって決定することができないので、これは問題ではないかもしれません。 LISは、この場合にのみ、正常な動作ですNATによって割り当てられたバインディングNATのパブリックIPアドレスを参照してくださいます。リターンルータビリティチェックのためのIPアドレスのプロパティは、要求を提出したアドレスに位置情報を返すことが魅力です。敵は、デバイスの場所を学びたい場合は（それがサブネットワーク上またはLISへのパスに沿ったルータである場合を除く）（特定のIPアドレスで識別される）、それは、応答メッセージが表示されません。
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.
共用媒体上に、敵対者は、他のデバイスの位置情報を求めることができます。敵対者は、このようなリンク層暗号化などのセキュリティメカニズムが、所定の位置にない限り、それは、共有媒体上で盗聴されているので、応答メッセージを参照することができるであろう。 NATの背後にいる顧客宅内における複数のデバイスと3.1節に示すようにネットワーク展開では、LISは、個々のデバイスを区別することができません。 3.3節に示すように、ホテルに見られるような敵対者はデータトラフィックを盗聴し、その後、より詳細な位置情報（例えば、特定の部屋番号）を学ぶためにLISにクエリ内のIPアドレスを偽装するためにWLAN展開で、それが可能です。このような攻撃は、例えば、ホテルの宿泊客のプライバシーを危険にさらす可能性があります。
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を動作させます。これは、今度は、この1つはデバイスに最も近いので、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デバイスとのntES、などのレガシーデバイスを、考慮しなければなりません。
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を提供し、それによってLIS要求がVPNトンネルを介して開始されたかどうかを検出することができます。
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の設計は、デバイスがアクセスネットワークトポロジーを認識していると仮定してはいけません。デバイスは、しかし、そのようなネットワークを介してユーザデータグラムプロトコル（UDP）の単純トラバーサル翻訳器（NAT）のアドレス（STUN）などのメカニズム、[RFC5389]またはシグナリングにおける次のステップ（NSIS）を介して、そのパブリック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は、実装に必須のLISディスカバリメカニズムを定義しなければなりません。
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>要素を挿入する必要があり、プレゼンス文書の要素（[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:
ジオロケーションL7ロケーション・コンフィギュレーション・プロトコル、デバイス（およびそのようなデバイスの人間のユーザ、適用可能な場合）を使用して、不正なエンティティが位置情報を受信することにより、プライバシーリスクに自分自身を公開。要求者に機密保護された場所を提供することは、4つのステップの成功に依存します。
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ワーキンググループのGEOPRIVレイヤ7場所構成要件の設計チームの共同作業です。貢献者はヘニングSchulzrinneと、バーバラ・スターク、マーク・Linsner、アンドリュー・ニュートン、ジェームズ・ウィンターボトム、マーティン・トムソン、ロハンマーイ、ブライアン・ローゼン、ジョンピーターソン、およびハンネスTschofenigが含まれます。
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作業部会の議長、アンディ・ニュートン、ランディGellens、およびアリソンマンキンに感謝したいと思います。さらに、我々は、Jabberのチャット会議を設定するための、および電話会議の議論に参加するため、設計チームのメーリングリスト中に彼のサポートのためのアンディ・ニュートンに感謝したいと思います。
The design team members can be reached at:
設計チームのメンバーはに到達することができます。
Marc Linsner: mlinsner@cisco.com
マルク・Linsner：mlinsner@cisco.com
Rohan Mahy: rohan@ekabal.com
ロハンマーイ：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
ヘニングSchulzrinneと：hgs@cs.columbia.edu
Barbara Stark: Barbara.Stark@bellsouth.com
バーバラ・スターク：Barbara.Stark@bellsouth.com
Martin Thomson: Martin.Thomson@andrew.com
マーティン・トムソン：Martin.Thomson@andrew.com
Hannes Tschofenig: Hannes.Tschofenig@nsn.com
ハンネスTschofenig：Hannes.Tschofenig@nsn.com
James Winterbottom: James.Winterbottom@andrew.com
ジェームズ・ウィンターボトム：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、テッドハーディー、マーティン・ドーソン、リチャード・バーンズ、ジェームズ・ウィンターボトム、トム・テイラー、オトマールレンドル、マルク・Linsner、ブライアン・ローゼン、ロジャー・マーシャル、ガイ・キャノン、ダグStuard、エリックArolick、ダンRomascanu、ジェロームグルニエに感謝したいと思います、そのWGLCレビューコメントのためのマーティン・トムソン、バーバラ・スターク、マイケルHaberler、そしてメアリー・バーンズ。
The authors would like to thank NENA for their work on [NENA] as it helped to provide some of the initial thinking.
著者はそれが最初の思考の一部を提供するのに役立ったようNENA]上の自分の仕事のためにNENAに感謝したいと思います。
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処理の一環として、彼のフィードバックのためのカレン・ジェニングスに感謝したいと思います。さらに、我々はアレクセイ・メルニコフ、ダンRomascanu、およびロバート・スパークスに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.マーシャル、 "インターネット技術との緊急コンテキスト解決のための要件"、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]、2005年5月、 "ローカルおよびメトロポリタンエリアネットワーク駅とメディアアクセス制御接続性発見のためのIEEE 802.1AB-2005 IEEE規格"、<のhttp：// standards.ieee.org/getieee802/download/ 802.1AB-2005。 PDF>。
[CDP] Wikipedia, "Cisco Discovery Protocol (CDP)", <http:// en.wikipedia.org/wiki/Cisco_Discovery_Protocol>.
[CDP]ウィキペディア、 "シスコ検出プロトコル（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]バーンズ、R.、Lepinski、M.、クーパー、A.、モリス、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]マーシャル、R.、エド。、 "場所・バイ・リファレンス・メカニズムのための要件"、進歩、2009年11月の作業。
[LIS-DISC] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", Work in Progress, February 2010.
[LIS-DISC]トムソン、M.とJ.ウィンターボトム、 "ローカル位置情報サーバー（LIS）を検出"、進歩、2010年2月での作業。
[LIS2LIS] Winterbottom, J. and S. Norreys, "LIS to LIS Protocol Requirements", Work in Progress, November 2007.
[LIS2LIS]ウィンターボトム、J.とS. Norreys、 "LIS LIS議定書の要件"、進歩、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、IPベースの緊急サービスサポートするための場所の決意について問題1、2006（2006年12月21日）、NENA推奨メソッド（S） - 技術情報ドキュメント（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.、アウン、C.、およびE.デイヴィス、 "NAT /ファイアウォールNSISシグナリング層プロトコル（NSLP）"、進歩、2010年2月ワーク。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]カッツ、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.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068]のHuitema、C.、 "6to4のリレールーターのエニーキャストプレフィックス"、RFC 3068、2001年6月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、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]ピーターソン、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]レモン、T.とB.ゾンマーフェルト、RFC 4361、2006年2月「動的ホスト構成プロトコルバージョン四つ（のDHCPv4）のためのノード固有のクライアント識別子」。
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[RFC4479]ローゼンバーグ、J.、 "プレゼンスのためのAデータモデル"、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.、ターラー、D.、およびL. Esibov、 "リンクローカルマルチキャスト名前解決（LLMNR）"、RFC 4795、2007年1月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]モスコウィッツ、R.、Nikander、P.、Jokela、P.、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、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]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "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]ウィンターボトム、J.、トムソン、M.、およびH. Tschofenig、 "GEOPRIVプレゼンス情報データフォーマット場所オブジェクト（PIDF-LO）使用法の明確化、考慮事項、および推奨事項"、RFC 5491、2009年3月。
[TEREDO-SEL] Ward, N., "Teredo Server Selection", Work in Progress, July 2007.
[TEREDO-SEL]ウォード、N.、 "Teredoサーバーの選択"、進歩、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] "TR069、CPE WAN管理プロトコルバージョン1.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の]チェシャー、S.とM. Krochmal、 "マルチキャストDNS"、進歩、2009年9月での作業。
Authors' Addresses
著者のアドレス
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
ハンネスTschofenigノキアシーメンスネットワークスLinnoitustie 6 02600エスポー、フィンランド
Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at
電話番号：+358（50）4871445 Eメール：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コンピュータサイエンスビル、ニューヨーク、NY 10027米国のヘニングSchulzrinneとコロンビア大学学部
Phone: +1 212 939 7004 EMail: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu
電話：+1 212 939 7004 Eメール：hgs+ecrit@cs.columbia.edu URI：http://www.cs.columbia.edu