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
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.
本文件提供了GeoDriv第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批准的所有文件都适用于任何级别的互联网标准；见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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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:
本文件提供了GeoDriv第7层（L7）位置配置协议（LCP）的问题陈述、要求列表和设计要点。该议定书有两个目的：
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 设备使用它从专用节点（称为位置信息服务器（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）。此引用可以采用订阅URI的形式，例如基于SIP状态的统一资源标识符（URI）、HTTP/HTTPS 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.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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)).
本文件还使用了[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.
对于术语“接入网络提供商”，我们指的是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）网络场景。接入网络提供商操作链路层和网络层设备（表示为节点）以及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 |
| |
+---------------------------+
+---------------------------+
| |
| 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.
客户场所网络由一个路由器和一个DHCP服务器组成，路由器带有一个带有端口地址转换的网络地址转换器（NAPT）和一个DHCP服务器，如大多数客户场所网络（CPN）和网络终端设备（NTE）中所用，其中第1层和有时第2层协议被终止。家庭网络中的路由器（例如，宽带路由器、电缆或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. 单机
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）；可能有桥接DSL或电缆调制解调器作为NTE，或者以太网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. 通过基于USB的DSL访问或在PC上使用ATM（PPPoA）、PPPoE或DHCP上的点对点协议的电缆调制解调器访问。
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. 至少有一个路由器的一个或多个主机（DHCP客户端或PPPoE、路由器中的DHCP服务器；IP语音（VoIP）可以是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/路由器对WAN提供PPPoE或DHCP，路由器为LAN中的主机提供DHCP服务器；双NAT）。
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 | |
|+--------+ +--------+ |
+--------------------------+
+--------------------------+
| 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 |
+------+
+--------------------------+
| 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第7层位置配置协议设计团队讨论的机制。包括它们是为了显示问题空间中的挑战，并出于完整性原因列出。它们并不意味着就任何机制达成共识，也不意味着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）可能是查找LIS的完全限定域名（FQDN）或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（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]和[MDN]）。不幸的是，这些机制只在本地链接上起作用。
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]的样式定义（IPv4和IPv6）选播地址，允许设备将发现数据包路由到最近的LIS。请注意，此过程仅用于发现，因此类似于[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呈现给设备。当设备发现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.
请注意，本节列出了GEOPRIV第7层位置配置协议设计团队讨论的机制。包括它们是为了显示问题空间中的挑战，并出于完整性原因列出。它们并不意味着就任何机制达成共识，也不意味着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。隐式地指沿着设备和LIS之间的路径的设备修改标识符的情况，就像使用基于IP地址的标识符时NAT所做的那样。
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.
需要尽量减少误用，使非路径对手不能获得其他设备的位置信息。同一子网中的路径上对手不应能够欺骗同一子网中另一设备的标识符。
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在数字用户线路接入多路复用器（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发现协议（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.
[RFC3972]引入了加密生成地址（CGA）的概念。基本思想是将公钥的截断散列放入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网络中，在许多情况下，用户凭证仅由家庭路由器知道，而不是在设备本身进行配置。对于网络，只有在执行网络访问身份验证过程时，经过身份验证的用户身份才可用。在漫游的情况下，用户的身份可能对接入网络不可用，因为安全协议可能提供用户身份保密性，从而隐藏用户的真实身份，从而允许接入网络仅看到假名或随机字符串。
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地址可用于位置确定。如果设备位于一个或多个NAT后面，则LIS无法看到此IP地址。这可能不是问题，因为位于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无法区分各个设备。对于酒店中的WLAN部署，如第3.3节所示，对手可能窃听数据流量，然后在查询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设备和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的设计不得假设设备知道接入网络拓扑。然而，设备能够通过诸如通过网络地址转换器（NAT）（STUN）[RFC5389]简单遍历用户数据报协议（UDP）或信令（NSIS）NAT/防火墙NSIS信令层协议（NSLP）[NSLP]中的下一步骤等机制来确定其公共IP地址。
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>元素放入状态文档的<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:
通过使用地理位置L7位置配置协议，设备（以及此类设备的人类用户，如果适用）将自己暴露于隐私风险中，由此未经授权的实体接收位置信息。向请求者提供受保密保护的位置取决于四个步骤的成功：
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工作组GEOPRIV第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工作组主席Andy Newton、Randy Gellens和Allison Mankin创建了设计团队。此外，我们还要感谢Andy Newton在设计团队邮件列表期间提供的支持、建立Jabber聊天会议以及参加电话会议讨论。
The design team members can be reached at:
可通过以下方式联系设计团队成员：
Marc Linsner: mlinsner@cisco.com
马克·林斯纳：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
乔恩·彼得森：乔恩。peterson@neustar.biz
Brian Rosen: br@brianrosen.net
布莱恩·罗森：br@brianrosen.net
Henning Schulzrinne: hgs@cs.columbia.edu
亨宁·舒尔兹林内：hgs@cs.columbia.edu
Barbara Stark: Barbara.Stark@bellsouth.com
芭芭拉·斯塔克：芭芭拉。Stark@bellsouth.com
Martin Thomson: Martin.Thomson@andrew.com
马丁·汤姆森：马丁。Thomson@andrew.com
Hannes Tschofenig: Hannes.Tschofenig@nsn.com
汉内斯：汉内斯。Tschofenig@nsn.com
James Winterbottom: James.Winterbottom@andrew.com
詹姆斯：詹姆斯。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、Jerome Grenier、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.
作者要感谢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.
作者还要感谢Cullen Jennings在IESG处理过程中提供的反馈。此外，我们还要感谢阿列克谢·梅尔尼科夫、丹·罗马斯坎努和罗伯特·斯帕克斯。
[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标准”，2005年5月，<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\u Discovery\u 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，“发现本地位置信息服务器（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协议要求”，正在进行的工作，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，2006年第1期（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]Stieemerling，M.，Tschofenig，H.，Aoun，C.，和E.Davies，“NAT/防火墙NSIS信令层协议（NSLP）”，正在进行的工作，2010年2月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]Katz，D.，“IP路由器警报选项”，RFC 21131997年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 28652000年6月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068]Huitema，C.，“6to4中继路由器的选播前缀”，RFC3068，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]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119]Peterson，J.，“一种基于状态的GEOPRIV定位对象格式”，RFC41192005年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.Erenen，“网络访问标识符”，RFC 42822005年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，“动态主机配置协议第四版（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，“链路本地多播名称解析（LLMNR）”，RFC 47952007年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，“主机身份协议”，RFC 52012008年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 54912009年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]“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.Krocmal，“多播DNS”，正在进行的工作，2009年9月。
Authors' Addresses
作者地址
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
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号
Phone: +1 212 939 7004
EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
Phone: +1 212 939 7004
EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu