Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 7216 Mozilla
Category: Standards Track R. Bellis
ISSN: 2070-1721 Nominet UK
April 2014
Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 7216 Mozilla
Category: Standards Track R. Bellis
ISSN: 2070-1721 Nominet UK
April 2014
Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS
使用IP地址和反向DNS的位置信息服务器（LIS）发现
Abstract
摘要
The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway.
住宅网关是一种已成为家庭网络设备组成部分的设备。发现位置信息服务器（LIS）是为基于位置的服务获取位置信息的必要部分。然而，当存在住宅网关时发现LIS会带来配置挑战，需要一种能够绕过网关提供的障碍的方法。
This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device.
本文档描述了此问题的解决方案。该解决方案基于分配给设备的网络地址，提供替代域名作为LIS发现过程的输入。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc7216.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7216.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Residential Gateway . . . . . . . . . . . . . . . . . . . 6
3.2. Security Features of Residential Gateways . . . . . . . . 7
4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 7
4.1. Identification of IP Addresses . . . . . . . . . . . . . 8
4.2. Domain Name Selection . . . . . . . . . . . . . . . . . . 9
4.3. Shortened DNS Names . . . . . . . . . . . . . . . . . . . 9
4.4. When To Use the Reverse DNS Method . . . . . . . . . . . 10
4.5. Private Address Spaces . . . . . . . . . . . . . . . . . 10
4.6. Necessary Assumptions and Restrictions . . . . . . . . . 11
4.7. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 12
4.8. Deployment Considerations . . . . . . . . . . . . . . . . 12
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Residential Gateway . . . . . . . . . . . . . . . . . . . 6
3.2. Security Features of Residential Gateways . . . . . . . . 7
4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 7
4.1. Identification of IP Addresses . . . . . . . . . . . . . 8
4.2. Domain Name Selection . . . . . . . . . . . . . . . . . . 9
4.3. Shortened DNS Names . . . . . . . . . . . . . . . . . . . 9
4.4. When To Use the Reverse DNS Method . . . . . . . . . . . 10
4.5. Private Address Spaces . . . . . . . . . . . . . . . . . 10
4.6. Necessary Assumptions and Restrictions . . . . . . . . . 11
4.7. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 12
4.8. Deployment Considerations . . . . . . . . . . . . . . . . 12
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16
A Location Information Server (LIS) is a service provided by an access network. The LIS uses knowledge of the access network topology and other information to generate location information for Devices. Devices within an access network are able to acquire location information from a LIS.
位置信息服务器（LIS）是由接入网络提供的服务。LIS使用接入网络拓扑知识和其他信息来生成设备的位置信息。接入网络内的设备能够从LIS获取位置信息。
The relationship between a Device and an access network might be transient. Configuration of the correct LIS at the Device ensures that accurate location information is available. Without location information, some network services are not available.
设备和接入网络之间的关系可能是暂时的。在设备上配置正确的LIS可确保提供准确的位置信息。如果没有位置信息，某些网络服务将不可用。
The configuration of a LIS IP address on a Device requires some automated process. This is particularly relevant when one considers that Devices might move between different access networks served by different LISs. LIS Discovery [RFC5986] describes a method that employs the Dynamic Host Configuration Protocol (DHCPv4 [RFC2131], DHCPv6 [RFC3315]) as input to U-NAPTR [RFC4848] discovery.
设备上LIS IP地址的配置需要一些自动化过程。当考虑到设备可能在由不同LIS服务的不同接入网络之间移动时，这一点尤其重要。LIS发现[RFC5986]描述了一种使用动态主机配置协议（DHCPv4[RFC2131]，DHCPv6[RFC3315]）作为U-NAPTR[RFC4848]发现输入的方法。
A residential gateway, or home router, provides a range of networking functions for Devices within the network it serves. Unfortunately, in most cases these functions effectively prevent the successful use of DHCP for LIS discovery.
住宅网关或家庭路由器为其服务的网络内的设备提供一系列联网功能。不幸的是，在大多数情况下，这些功能有效地阻止了成功使用DHCP进行LIS发现。
One drawback with DHCP is that universal deployment of a new option takes a considerable amount of time. Often, networking equipment needs to be updated in order to support the new option. Of particular concern are the millions of residential gateway devices used to provide Internet access to homes and businesses. While [RFC5986] describes functions that can be provided by residential gateways to support LIS discovery, gateways built before the publication of this specification are not expected (and are likely not able) to provide these functions.
DHCP的一个缺点是，通用部署新选项需要相当长的时间。通常，网络设备需要更新以支持新选项。特别令人关注的是，数百万住宅网关设备用于为家庭和企业提供互联网接入。虽然[RFC5986]描述了住宅网关可以提供的功能，以支持LIS发现，但在本规范发布之前构建的网关预计不会（也可能无法）提供这些功能。
This document explores the problem of configuring Devices with a LIS address when a residential gateway is interposed between the Device and access network. Section 3 defines the problem, and Section 4 describes a method for determining a domain name that can be used for discovery of the LIS.
本文档探讨了在设备和接入网络之间插入住宅网关时，使用LIS地址配置设备的问题。第3节定义了问题，第4节描述了确定可用于发现LIS的域名的方法。
In some cases, the solution described in this document is based on a UNilateral Self-Address Fixing (UNSAF) [RFC3424] method. For those cases, this solution is considered transitional until such time as the recommendations for residential gateways in [RFC5986] are more widely deployed. Considerations relating to UNSAF applications are described in Section 7.
在某些情况下，本文档中描述的解决方案基于单边自地址固定（UNSAF）[RFC3424]方法。对于这些情况，在[RFC5986]中关于住宅网关的建议得到更广泛的部署之前，此解决方案被视为过渡方案。与UNSAF申请有关的注意事项见第7节。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document uses terminology established in [RFC6280] and [RFC5012]. The terms "Device" and "LIS" are capitalized throughout when they are used to identify the roles defined in [RFC6280].
本文件使用[RFC6280]和[RFC5012]中确定的术语。术语“设备”和“LIS”在用于识别[RFC6280]中定义的角色时始终大写。
Figure 1 shows a simplified network topology for fixed wire-line Internet access. This arrangement is typical when wired Internet access is provided. The diagram shows two network segments: the access network provided by an Internet service provider (ISP), and the residential network served by the residential gateway.
图1显示了固定线路互联网接入的简化网络拓扑。当提供有线互联网接入时，这种安排是典型的。该图显示了两个网段：由互联网服务提供商（ISP）提供的接入网络和由住宅网关提供服务的住宅网络。
There are a number of variations on this arrangement, as documented in Section 3.1 of [RFC5687]. In each of these variations, the goal of LIS discovery is to identify the LIS in the access network.
如[RFC5687]第3.1节所述，该安排有许多变化。在这些变体中，LIS发现的目标是识别接入网络中的LIS。
________
(/ \)
(( Internet ))
(\________/)
|
|
.- - -|- - - - - - - - - - - -.
( | )
( +--------+ +-------+ )
Access ( | Access |. . . .| LIS | )
Network ( | Node | | | )
(ISP) ( +--------+ +-------+ )
( \ \ )
`- - - -\- - - - - - - -\- - -'
\ \
\ |
.- - - - -\- - - - - - - + -.
( \ | )
( +-------------+ : )
( | Residential | | )
Residential ( | Gateway | : )
Network ( +-------------+ | )
( / \ / )
( / \ / )
( +--------+ +--------+ )
( | Device | | Device | )
( +--------+ +--------+ )
( )
`- - - - - - - - - - - - - -'
________
(/ \)
(( Internet ))
(\________/)
|
|
.- - -|- - - - - - - - - - - -.
( | )
( +--------+ +-------+ )
Access ( | Access |. . . .| LIS | )
Network ( | Node | | | )
(ISP) ( +--------+ +-------+ )
( \ \ )
`- - - -\- - - - - - - -\- - -'
\ \
\ |
.- - - - -\- - - - - - - + -.
( \ | )
( +-------------+ : )
( | Residential | | )
Residential ( | Gateway | : )
Network ( +-------------+ | )
( / \ / )
( / \ / )
( +--------+ +--------+ )
( | Device | | Device | )
( +--------+ +--------+ )
( )
`- - - - - - - - - - - - - -'
Figure 1: Simplified Network Topology
图1：简化的网络拓扑
A particularly important characteristic of this arrangement is the relatively small geographical area served by the residential gateway. Given a small enough area, it is reasonable to delegate the responsibility for providing Devices within the residential network with location information to the ISP. The ISP is able to provide location information that identifies the residence, which should be adequate for a wide range of purposes.
这种安排的一个特别重要的特点是住宅网关所服务的地理区域相对较小。考虑到足够小的区域，将为住宅网络内的设备提供位置信息的责任委托给ISP是合理的。ISP能够提供识别住所的位置信息，这些信息应足以用于广泛的用途。
A residential network that covers a larger geographical area might require a dedicated LIS, a case that is outside the scope of this document.
覆盖更大地理区域的住宅网络可能需要专用LIS，这种情况不在本文件范围内。
The goal of LIS discovery is to identify a LIS that is able to provide the Device with accurate location information. In the network topology described, this means identifying the LIS in the access network. The residential gateway is a major obstacle in achieving this goal.
LIS发现的目标是识别能够为设备提供准确位置信息的LIS。在所描述的网络拓扑中，这意味着识别接入网络中的LIS。住宅网关是实现这一目标的主要障碍。
A residential gateway can encompass several different functions including: modem, Ethernet switch, wireless access point, router, network address translation (NAT), DHCP server, DNS relay, and firewall. Of the common functions provided, the NAT function of a residential gateway has the greatest impact on LIS discovery.
住宅网关可以包含几个不同的功能，包括：调制解调器、以太网交换机、无线接入点、路由器、网络地址转换（NAT）、DHCP服务器、DNS中继和防火墙。在提供的常见功能中，住宅网关的NAT功能对LIS发现的影响最大。
An ISP is typically parsimonious about their IP address allocations; each customer is allocated a limited number of IP addresses. Therefore, NAT is an extremely common function of gateways. NAT enables the use of multiple Devices within the residential network. However, NAT also means that Devices within the residence are not configured by the ISP directly.
ISP在IP地址分配方面通常很吝啬；为每个客户分配有限数量的IP地址。因此，NAT是网关极为常见的功能。NAT允许在住宅网络中使用多个设备。然而，NAT也意味着住宅内的设备不是由ISP直接配置的。
When it comes to discovering a LIS, the fact that Devices are not configured by the ISP causes a significant problem. Configuration is the ideal method of conveying the information necessary for discovery. Devices attached to residential gateways are usually given a generic configuration that includes no information about the ISP network. For instance, DNS configuration typically points to a DNS relay on the gateway device. This approach ensures that the local network served by the gateway is able to operate without a connection to the ISP, but it also means that Devices are effectively ignorant of the ISP network.
在查找LIS时，ISP未配置设备这一事实会导致一个重大问题。配置是传递发现所需信息的理想方法。连接到住宅网关的设备通常具有通用配置，其中不包含有关ISP网络的信息。例如，DNS配置通常指向网关设备上的DNS中继。这种方法确保了网关所服务的本地网络能够在没有ISP连接的情况下运行，但也意味着设备实际上不知道ISP网络。
[RFC5986] describes several methods that can be applied by a residential gateway to assist Devices in acquiring location information. For instance, the residential gateway could forward LIS address information to hosts within the network it serves. Unfortunately, such an active involvement in the discovery process only works for new residential gateway devices that implement those recommendations.
[RFC5986]描述了住宅网关可以应用的几种方法，以帮助设备获取位置信息。例如，住宅网关可以将LIS地址信息转发给它所服务的网络内的主机。不幸的是，这种积极参与发现过程的做法只适用于实施这些建议的新住宅网关设备。
Where residential gateways already exist, direct involvement of the gateway in LIS discovery requires that the residential gateway be updated or replaced. The cost of replacement is difficult to justify to the owner of the gateway, especially when it is considered that the gateway still fills its primary function: Internet access. Furthermore, updating the software in such devices is not feasible in
如果已经存在住宅网关，则直接参与LIS发现需要更新或更换住宅网关。更换成本很难向网关所有者证明，特别是当考虑到网关仍然履行其主要功能：互联网接入时。此外，在这种设备中更新软件在任何情况下都是不可行的
many cases. Even if software updates were made available, many residential gateways cannot be updated remotely, inevitably leading to some proportion that is not updated.
很多案例。即使软件更新可用，许多住宅网关也无法远程更新，不可避免地导致部分未更新。
This document therefore describes a method that can be used by Devices to discover their LIS without any assistance from the network.
因此，本文档描述了一种方法，设备可以使用该方法来发现其LIS，而无需网络的任何帮助。
A network firewall function is often provided by residential gateways as a security measure. Security features like intrusion detection systems help protect users from attacks. Amongst these protections is a port filter that prevents both inbound and outbound traffic on certain TCP and UDP ports. Therefore, any solution needs to consider the likelihood of traffic being blocked.
住宅网关通常提供网络防火墙功能作为安全措施。入侵检测系统等安全功能有助于保护用户免受攻击。在这些保护措施中，有一个端口过滤器，用于防止某些TCP和UDP端口上的入站和出站流量。因此，任何解决方案都需要考虑交通阻塞的可能性。
LIS discovery [RFC5986] uses a DNS-based Dynamic Delegation Discovery Service (DDDS) system as the basis of discovery. Input to this process is a domain name. Use of DHCP for acquiring the domain name is specified, but alternative methods of acquisition are permitted.
LIS发现[RFC5986]使用基于DNS的动态委托发现服务（DDDS）系统作为发现的基础。此过程的输入是域名。指定使用DHCP获取域名，但允许使用其他获取方法。
This document specifies a means for a Device to discover several alternative domain names that can be used as input to the DDDS process. These domain names are based on the IP address of the Device. Specifically, the domain names are a portion of the reverse DNS trees -- either the ".in-addr.arpa." or ".ip6.arpa." tree.
本文档规定了一种设备发现多个可选域名的方法，这些域名可用作DDDS进程的输入。这些域名基于设备的IP地址。具体来说，域名是反向DNS树的一部分--“.in addr.arpa.”或“.ip6.arpa.”树。
The goal of this process is to make a small number of DDDS queries in order to find a LIS. After LIS discovery using the DHCP-based process in [RFC5986] has failed, a Device can:
此过程的目标是进行少量DDDS查询以查找LIS。在[RFC5986]中使用基于DHCP的进程进行LIS发现失败后，设备可以：
1. Collect a set of IP addresses that refer to the Device (Section 4.1).
1. 收集一组与设备相关的IP地址（第4.1节）。
2. Convert each IP address into DNS names in the "in-addr.arpa." or "ip6.arpa." tree (Section 4.2).
2. 将每个IP地址转换为“in addr.arpa.”或“ip6.arpa.”树（第4.2节）中的DNS名称。
3. Perform the DDDS process for LIS discovery on those DNS names ([RFC5986]).
3. 在这些DNS名称（[RFC5986]）上执行DDDS过程以发现LIS。
4. Shorten the DNS names by some number of labels and repeat the DDDS process (Section 4.3).
4. 将DNS名称缩短一定数量的标签，并重复DDDS过程（第4.3节）。
A Device might be reachable at one of a number of IP addresses. In the process described, a Device first identifies each IP address from which it is potentially reachable. From each of these addresses, the Device then selects up to three domain names for use in discovery. These domain names are then used as input to the DDDS process.
可以在多个IP地址之一访问设备。在所描述的过程中，设备首先识别其潜在可访问的每个IP地址。然后，设备从每个地址中选择最多三个域名用于发现。然后将这些域名用作DDDS进程的输入。
A Device identifies a set of potential IP addresses that currently result in packets being routed to it. These are ordered by proximity, with those addresses that are used in adjacent network segments being favored over those used in public or remote networks. The first addresses in the set are those that are assigned to local network interfaces.
设备标识一组可能的IP地址，这些地址当前导致数据包被路由到设备。这些地址是按邻近性排序的，在相邻网段中使用的地址比在公共或远程网络中使用的地址更受青睐。集合中的第一个地址是分配给本地网络接口的地址。
A Device can use the Session Traversal Utilities for NAT (STUN) [RFC5389] mechanism to determine its public, reflexive transport address. The host uses the "Binding Request" message and the resulting "XOR-MAPPED-ADDRESS" parameter that is returned in the response.
设备可以使用NAT（STUN）[RFC5389]机制的会话遍历实用程序来确定其公共、自反传输地址。主机使用“Binding Request”消息和响应中返回的结果“XOR-MAPPED-ADDRESS”参数。
Alternative methods for determining other IP addresses MAY be used by the Device. If enabled, the Port Control Protocol (PCP) [RFC6887], Universal Plug and Play (UPnP) [UPnP-IGD-WANIPConnection1], and NAT Port Mapping Protocol (NAT-PMP) [RFC6886] are each able to provide the external address of a residential gateway device. These, as well as proprietary methods for determining other addresses, might be available. Because there is no assurance that these methods will be supported by any access network, these methods are not mandated. Note also that in some cases, methods that rely on the view of the network from the residential gateway device could reveal an address in a private address range (see Section 4.6).
设备可以使用用于确定其他IP地址的替代方法。如果启用，端口控制协议（PCP）[RFC6887]、通用即插即用（UPnP）[UPnP-IGD-WANIPConnection1]和NAT端口映射协议（NAT-PMP）[RFC6886]都能够提供住宅网关设备的外部地址。这些，以及用于确定其他地址的专有方法，可能是可用的。由于无法保证这些方法将得到任何接入网络的支持，因此这些方法不是强制性的。还请注意，在某些情况下，依赖于住宅网关设备的网络视图的方法可能会显示专用地址范围内的地址（参见第4.6节）。
In many instances, the IP address produced might be from a private address range. For instance, the address on a local network interface could be from a private range allocated by the residential gateway. In other cases, methods that rely on the view of the network (UPnP, NAT-PMP) from the residential gateway device could reveal an address in a private address range if the access network also uses NAT. For a private IP address, the derived domain name is only usable where the employed DNS server contains data for the corresponding private IP address range.
在许多情况下，生成的IP地址可能来自专用地址范围。例如，本地网络接口上的地址可以来自住宅网关分配的专用范围。在其他情况下，如果接入网络也使用NAT，则依赖于来自住宅网关设备的网络视图（UPnP、NAT-PMP）的方法可以揭示私有地址范围内的地址。对于专用IP地址，仅当使用的DNS服务器包含相应专用IP地址范围的数据时，派生域名才可用。
The domain name selected for each resulting IP address is the name that would be used for a reverse DNS lookup. The domain name derived from an IP version 4 address is in the ".in-addr.arpa." tree and follows the construction rules in Section 3.5 of [RFC1035]. The domain name derived from an IP version 6 address is in the ".ip6.arpa." tree and follows the construction rules in Section 2.5 of [RFC3596].
为每个结果IP地址选择的域名是将用于反向DNS查找的名称。从IP版本4地址派生的域名位于“.in addr.arpa.”树中，并遵循[RFC1035]第3.5节中的构造规则。从IP版本6地址派生的域名位于“.ip6.arpa.”树中，并遵循[RFC3596]第2.5节中的构造规则。
Additional domain names are added to allow for a single DNS record to cover a larger set of addresses. If the search on the domain derived from the full IP address does not produce a NAPTR record with the desired service tag (e.g., "LIS:HELD"), a similar search is repeated based on a shorter domain name, using a part of the IP address:
添加额外的域名以允许单个DNS记录覆盖更大的地址集。如果从完整IP地址派生的域上的搜索未生成具有所需服务标签（例如，“LIS:HOLD”）的NAPTR记录，则会使用IP地址的一部分，基于较短的域名重复类似的搜索：
o For IP version 4, the resulting domain name SHOULD be shortened successively by one and two labels, and the query repeated. This corresponds to a search on a /24 or /16 network prefix. This allows for fewer DNS records in the case where a single access network covering an entire /24 or /16 network is served by the same LIS.
o 对于IP版本4，生成的域名应依次缩短一个和两个标签，并重复查询。这对应于对/24或/16网络前缀的搜索。这允许在覆盖整个/24或/16网络的单个接入网络由同一LIS服务的情况下减少DNS记录。
o For IP version 6, the resulting domain SHOULD be shortened successively by 16, 18, 20, and 24 labels, and the query repeated. This corresponds to a search on a /64, /56, /48, or /32 network prefix.
o 对于IP版本6，结果域应依次缩短16、18、20和24个标签，并重复查询。这对应于对/64、/56、/48或/32网络前缀的搜索。
This set of labels is intended to provide network operators with a degree of flexibility in where LIS discovery records can be placed without significantly increasing the number of DNS names that are searched. This does not attach any other significance to these specific zone cuts or create a classful addressing hierarchy based on the reverse DNS tree.
这组标签旨在为网络运营商提供一定程度的灵活性，以便在不显著增加搜索的DNS名称数量的情况下放置LIS发现记录。这不会对这些特定区域切割附加任何其他意义，也不会基于反向DNS树创建一个类寻址层次结构。
For example, the IPv4 address "192.0.2.75" could result in queries to:
例如，IPv4地址“192.0.2.75”可能导致查询：
o 75.2.0.192.in-addr.arpa.
o 75.2.0.192.in-addr.arpa。
o 2.0.192.in-addr.arpa.
o 2.0.192.in-addr.arpa。
o 0.192.in-addr.arpa.
o 0.192.in-addr.arpa。
Similarly, the IPv6 address "2001:DB8::28e4:3a93:4429:dfb5" could result in queries to:
类似地，IPv6地址“2001:DB8:：28e4:3a93:4429:dfb5”可能导致查询：
o 5.b.f.d.9.2.4.4.3.9.a.3.4.e.8.2.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2 .ip6.arpa.
o 5.b.f.d.9.2.4.4.3.9.a.3.4.e.8.2.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa。
o 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
o 0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.0.2.ip6.arpa。
o 0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
o 0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa。
o 0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
o 0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa。
o 8.b.d.0.1.0.0.2.ip6.arpa.
o 8.b.d.0.1.0.0.2.ip6.arpa。
The limited number of labels by which each name is shortened is intended to limit the number of DNS queries performed by Devices. If no LIS is discovered by this method, the result will be that no more than five U-NAPTR resolutions are invoked for each IP address.
缩短每个名称的标签的有限数量旨在限制设备执行的DNS查询的数量。如果此方法未发现任何LIS，则结果将是每个IP地址调用的U-NAPTR解析不超过五个。
The DHCP method described in [RFC5986] MUST be attempted on all local network interfaces before attempting this method. This method is employed either because DHCP is unavailable, when the DHCP server does not provide a value for the access network domain name option, or because a request to the resulting LIS results in a HELD "notLocatable" error or equivalent.
在尝试此方法之前，必须在所有本地网络接口上尝试[RFC5986]中描述的DHCP方法。使用此方法的原因可能是DHCP不可用，当DHCP服务器未提供访问网络域名选项的值时，或者由于对结果LIS的请求导致保留的“notLocatable”错误或等效错误。
Addresses from a private-use address space can be used as input to this method. In many cases, this applies to addresses defined in [RFC1918], though other address ranges could have limited reachability where this advice also applies. This is only possible if a DNS server with a view of the same address space is used. Public DNS servers cannot provide useful records for private addresses.
来自专用地址空间的地址可以用作此方法的输入。在许多情况下，这适用于[RFC1918]中定义的地址，尽管其他地址范围的可达性可能有限，但此建议也适用。这仅在使用具有相同地址空间视图的DNS服务器时才可能。公共DNS服务器无法为专用地址提供有用的记录。
Using an address from a private space in discovery can provide a more specific answer if the DNS server has records for that space. Figure 2 shows a network configuration where addresses from an ISP network could better indicate the correct LIS. Records in DNS B can be provided for the 10.0.0.0/8 range, potentially dividing that range so that a more local LIS can be selected.
如果DNS服务器具有该空间的记录，则在发现中使用来自私有空间的地址可以提供更具体的答案。图2显示了一种网络配置，其中来自ISP网络的地址可以更好地指示正确的LIS。可以为10.0.0.0/8范围提供DNS B中的记录，可能会划分该范围，以便可以选择更多本地LIS。
_____ ________
( DNS ).....(/ \) Public
(__A__) (( Internet )) Address
(\________/) Space
|
[NAT]
_____ _____|_____
( DNS )....(/ \) Private
(__B__) (( ISP Network )) Address Space
(\___________/) (e.g., 10.0.0.0/8)
|
[Gateway]
____|____
(/ \) Private
(( Residence )) Address Space
(\_________/) (e.g., 192.168.0.0/16)
_____ ________
( DNS ).....(/ \) Public
(__A__) (( Internet )) Address
(\________/) Space
|
[NAT]
_____ _____|_____
( DNS )....(/ \) Private
(__B__) (( ISP Network )) Address Space
(\___________/) (e.g., 10.0.0.0/8)
|
[Gateway]
____|____
(/ \) Private
(( Residence )) Address Space
(\_________/) (e.g., 192.168.0.0/16)
Figure 2: Address Space Example
图2：地址空间示例
The goal of automatic DNS configuration is usually to select a local DNS, which suits configurations like the one shown. However, use of public DNS or STUN servers means that a public IP address is likely to be found. For STUN in particular, selecting a public server minimizes the need for reconfiguration when a Device moves. Adding records for the public address space used by an access network ensures that the discovery process succeeds when a public address is used.
自动DNS配置的目标通常是选择一个本地DNS，它适合所示的配置。但是，使用公共DNS或STUN服务器意味着可能会找到公共IP地址。特别是对于STUN，当设备移动时，选择公共服务器可以最大限度地减少重新配置的需要。为接入网络使用的公共地址空间添加记录可确保在使用公共地址时发现过程成功。
When used by a Device for LIS discovery, this is an UNSAF application and is subject to the limitations described in Section 7.
当设备用于LIS发现时，这是UNSAF应用程序，受第7节所述限制的约束。
It is not necessary that the IP address used is unique to the Device, only that the address can be somehow related to the Device or the access network that serves the Device. This allows a degree of flexibility in determining this value, although security considerations (Section 6) might require that the address be verified to limit the chance of falsification.
所使用的IP地址不一定是设备的唯一地址，只是该地址可以以某种方式与设备或服务于该设备的接入网络相关。这允许在确定该值时具有一定程度的灵活性，尽管出于安全考虑（第6节）可能需要验证地址以限制篡改的机会。
This solution assumes that the public, reflexive transport address used by a Device is in some way controlled by the access network provider or some other related party. This implies that the corresponding ".in-addr.arpa." or ".ip6.arpa." record can be updated by that entity to include a useful value for the LIS address.
此解决方案假定设备使用的公共、自反传输地址以某种方式由接入网络提供商或其他相关方控制。这意味着该实体可以更新相应的“.in addr.arpa.”或“.ip6.arpa.”记录，以包含LIS地址的有用值。
Successful use of private addresses relies on a DNS server that has records for the address space that is used. Using a public IP address increases the likelihood of this. This document relies on STUN to provide the Device with a public, reflexive transport address. Configuration of a STUN server is necessary to ensure that this is successful.
私有地址的成功使用依赖于具有所使用地址空间记录的DNS服务器。使用公共IP地址会增加这种可能性。本文档依靠STUN为设备提供一个公共的、自反的传输地址。必须配置STUN服务器以确保此操作成功。
In cases where a virtual private network (VPN) or other tunnel is used, the entity providing a public IP address might not be able to provide the Device with location information. It is assumed that this entity is able to identify this problem and indicate this to the Device (using the "notLocatable" HELD error or similar). This problem is described in more detail in [RFC5985].
在使用虚拟专用网络（VPN）或其他隧道的情况下，提供公共IP地址的实体可能无法向设备提供位置信息。假设该实体能够识别该问题并向设备指示该问题（使用“notLocatable”保持错误或类似错误）。该问题在[RFC5985]中有更详细的描述。
An access network provider SHOULD provide NAPTR records for each public IP address that is used for Devices within the access network.
接入网提供商应为接入网内设备使用的每个公共IP地址提供NAPTR记录。
Any DNS server internal to a NAT SHOULD also include records for the private address range. These records might only be provided to clients making requests from the private address range. Doing so allows clients within the private address range to discover a LIS based on their IP address prior to any address translation. In geographically distributed networks that use a private address range, this enables the use of a different LIS for different locations, based on the IP address range used at each location. Use of a public, translated IP address for the network can still work, but it might result in a suboptimal LIS selection.
NAT内部的任何DNS服务器也应包括专用地址范围的记录。这些记录可能仅提供给从专用地址范围发出请求的客户端。这样做允许私有地址范围内的客户端在任何地址转换之前根据其IP地址发现LIS。在使用专用地址范围的地理分布网络中，这允许根据每个位置使用的IP地址范围为不同位置使用不同的LIS。为网络使用公共的、经过翻译的IP地址仍然可以工作，但这可能会导致次优的LIS选择。
A network that operates network address translation SHOULD provide NAPTR records that reference a LIS endpoint with a public address. This requires the reservation of an IP address and port for the LIS. To ensure requests toward the LIS from within the private address space do not traverse the NAT and have source addresses mapped by the NAT, networks can provide a direct route to the LIS. Clients that perform discovery based on public DNS or STUN servers are thereby easier to trace based on source address information.
运行网络地址转换的网络应提供引用具有公共地址的LIS端点的NAPTR记录。这需要为LIS保留IP地址和端口。为了确保从专用地址空间中向LIS发出的请求不会穿越NAT，并且源地址由NAT映射，网络可以提供到LIS的直接路由。因此，基于公共DNS或STUN服务器执行发现的客户端更容易基于源地址信息进行跟踪。
NAPTR records can be provided for individual IP addresses. To limit
the proliferation of identical records, a single record can be placed
at higher nodes of the tree (corresponding to /24 and /16 for IPv4;
/64, /56, /48, and /32 for IPv6). A record at a higher point in the
tree (those with a shorter prefix) applies to all addresses lower in
NAPTR records can be provided for individual IP addresses. To limit
the proliferation of identical records, a single record can be placed
at higher nodes of the tree (corresponding to /24 and /16 for IPv4;
/64, /56, /48, and /32 for IPv6). A record at a higher point in the
tree (those with a shorter prefix) applies to all addresses lower in
the tree (those with a longer prefix); records at the lower point override those at higher points, thus allowing for exceptions to be specified.
树（前缀较长的树）；较低点的记录覆盖较高点的记录，因此允许指定异常。
As with all uses of geolocation information, it is very important that measures be taken to ensure that location information is not provided to unauthorized parties. The mechanism defined in this document is focused on the case where a device is learning its own location so that it can provide that location information to applications. We assume that the device learning its own location is not a privacy risk. There are then two remaining privacy risks: the use of geolocation by applications, and the abuse of the location configuration protocol.
与地理位置信息的所有用途一样，必须采取措施确保不向未经授权的各方提供位置信息。本文档中定义的机制侧重于设备学习其自身位置的情况，以便向应用程序提供该位置信息。我们假设设备学习自己的位置不会带来隐私风险。还有两个剩余的隐私风险：应用程序使用地理位置，以及滥用位置配置协议。
The privacy considerations around the use of geolocation by applications vary considerably by application context. A framework for location privacy in applications is provided in [RFC6280].
应用程序使用地理位置时的隐私考虑因应用程序上下文的不同而有很大差异。[RFC6280]中提供了应用程序中位置隐私的框架。
The mechanism specified in this document allows a device to discover its local LIS, from which it then acquires its location using a Location Configuration Protocol (LCP) [RFC5687]. If an unauthorized third party can spoof the LCP to obtain a target's location information, then the mechanism in this document could allow them to discover the proper server to attack for a given IP address. Thus, it is important that a LIS meet the security requirements of the LCP it implements. For HELD, these requirements are laid out in Section 9 of [RFC5985].
本文档中指定的机制允许设备发现其本地LIS，然后使用位置配置协议（LCP）[RFC5687]从中获取其位置。如果未经授权的第三方可以欺骗LCP以获取目标的位置信息，则本文档中的机制可以允许他们发现要针对给定IP地址进行攻击的适当服务器。因此，LIS必须满足其实现的LCP的安全要求。对于HOLD，这些要求见[RFC5985]第9节。
A Device that discovers a LIS using the methods in this document MUST NOT provide that LIS with additional information that might reveal its position, such as the location measurements described in [RFC7105], unless it has a secondary method for determining the authenticity of the LIS, such as a white list.
使用本文件中的方法发现LIS的设备不得向LIS提供可能显示其位置的附加信息，如[RFC7105]中所述的位置测量，除非其具有确定LIS真实性的辅助方法，如白名单。
The security considerations described in [RFC5986] apply to the discovery process as a whole. The primary security concern is with the potential for an attacker to impersonate a LIS.
[RFC5986]中描述的安全注意事项适用于整个发现过程。主要的安全问题是攻击者可能模拟LIS。
The added ability for a third party to discover the identity of a LIS does not add any concerns, since the identity of a LIS is considered public information.
第三方发现LIS身份的附加功能不会增加任何问题，因为LIS的身份被视为公共信息。
In addition to existing considerations, this document introduces further security considerations relating to the identification of the IP address. It is possible that an attacker could attempt to provide a falsified IP address in an attempt to subvert the rest of the process.
除现有注意事项外，本文件还介绍了与IP地址标识相关的其他安全注意事项。攻击者可能试图提供伪造的IP地址，以破坏进程的其余部分。
[RFC5389] describes attacks where an attacker is able to ensure that a Device receives a falsified reflexive address. An on-path attacker might be able to ensure that a falsified address is provided to the Device. Even though STUN messages are protected by a STUN MESSAGE-INTEGRITY attribute, which is an HMAC that uses a shared secret, an on-path attacker can capture and modify packets, altering source and destination addresses to provide falsified addresses.
[RFC5389]描述了攻击者能够确保设备收到伪造的自反地址的攻击。路径上攻击者可能能够确保向设备提供伪造的地址。即使STUN消息受STUN消息完整性属性（使用共享秘密的HMAC）保护，路径上的攻击者也可以捕获和修改数据包，改变源地址和目标地址以提供伪造的地址。
This attack could result in an effective means of denial of service, or a means to provide a deliberately misleading service. Notably, any LIS that is identified based on a falsified IP address could still be a valid LIS for the given IP address, just not one that is useful for providing the Device with location information. In this case, the LIS provides a HELD "notLocatable" error or an equivalent. If the falsified IP address is under the control of the attacker, it is possible that misleading (but verifiable) DNS records could indicate a malicious LIS that provides false location information.
此攻击可能导致有效的拒绝服务手段，或故意提供误导性服务的手段。值得注意的是，基于伪造的IP地址识别的任何LIS仍然可以是给定IP地址的有效LIS，而不是用于向设备提供位置信息的LIS。在这种情况下，LIS提供保持的“notLocatable”错误或等效错误。如果伪造的IP地址在攻击者的控制下，则误导性（但可验证的）DNS记录可能表示提供虚假位置信息的恶意LIS。
In all cases of falsification, the best remedy is to perform some form of independent verification of the result. No specific mechanism is currently available to prevent attacks based on falsification of reflexive addresses; it is suggested that Devices attempt to independently verify that the reflexive transport address provided is accurate. An independent, trusted source of location information could aid in verification, even if the trusted source is unable to provide information with the same degree of accuracy as the discovered LIS.
在所有伪造的情况下，最好的补救办法是对结果进行某种形式的独立验证。目前没有特定的机制来防止基于自反地址伪造的攻击；建议设备尝试独立验证提供的自反传输地址是否准确。独立、可信的位置信息源可以帮助验证，即使可信源无法提供与所发现的LIS相同精度的信息。
Use of private address space effectively prevents use of the usual set of trust anchors for DNSSEC. Only a DNS server that is able to see the same private address space can provide useful records. A Device that relies on DNS records in the private address space portion of the ".in-addr.arpa." or ".ip6.arpa." trees MUST either use an alternative trust anchor for these records or rely on other means of ensuring the veracity of the DNS records.
私有地址空间的使用有效地防止了DNSSEC使用通常的信任锚集。只有能够看到相同私有地址空间的DNS服务器才能提供有用的记录。依赖“.in addr.arpa.”或“.ip6.arpa.”树的专用地址空间部分中的DNS记录的设备必须为这些记录使用替代信任锚，或依赖其他方法确保DNS记录的准确性。
DNS queries that are not blocked as [RFC6303] demands, or directed to servers outside the network, can cause the addresses that are in use within the network to be exposed outside of the network. For resolvers within the network, implementing [RFC6303] avoids this issue; otherwise, the problem cannot be avoided without blocking DNS queries to external servers.
未按[RFC6303]要求阻止或定向到网络外服务器的DNS查询可能会导致网络内正在使用的地址暴露在网络外。对于网络内的解析器，实现[RFC6303]可避免此问题；否则，如果不阻止对外部服务器的DNS查询，就无法避免该问题。
The IAB has studied the problem of Unilateral Self-Address Fixing (UNSAF) [RFC3424], which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism, such as STUN.
IAB已经研究了单边自地址固定（UNSAF）[RFC3424]问题，这是客户端通过协作协议反射机制（如STUN）尝试在NAT另一端的另一个域中确定其地址的一般过程。
This section only applies to the use of this method of LIS discovery by Devices and does not apply to its use for third-party LIS discovery.
本节仅适用于通过设备使用此LIS发现方法，不适用于其用于第三方LIS发现。
The IAB requires that protocol specifications that define UNSAF mechanisms document a set of considerations.
IAB要求定义UNSAF机制的协议规范记录一组注意事项。
1. Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal.
1. 精确定义一个具体的、范围有限的问题，该问题将通过UNSAF提案解决。
Section 3 describes the limited scope of the problem addressed in this document.
第3节描述了本文件中所述问题的有限范围。
2. Description of an exit strategy/transition plan.
2. 退出战略/过渡计划的说明。
[RFC5986] describes behavior that residential gateways require in order for this short-term solution to be rendered unnecessary. When implementations of the recommendations in LIS discovery are widely available, this UNSAF mechanism can be made obsolete.
[RFC5986]描述了住宅网关需要的行为，以使此短期解决方案变得不必要。当LIS发现中的建议实现广泛可用时，这种UNSAF机制可能会过时。
3. Discussion of specific issues that may render systems more "brittle".
3. 讨论可能使系统更“脆弱”的具体问题。
A description of the necessary assumptions and limitations of this solution are included in Section 4.6.
第4.6节介绍了该解决方案的必要假设和限制。
Use of STUN for discovery of a reflexive transport address is inherently brittle in the presence of multiple NATs or address realms. In particular, brittleness is added by the requirement of using a DNS server that is able to view the address realm that contains the IP address in question. If address realms use overlapping addressing space, then there is a risk that the DNS server provides information that is not useful to the Device.
在存在多个NAT或地址域的情况下，使用STUN发现自反传输地址本质上是脆弱的。特别是，使用能够查看包含所述IP地址的地址域的DNS服务器的要求增加了脆弱性。如果地址域使用重叠的寻址空间，则存在DNS服务器提供对设备不有用的信息的风险。
4. Identify requirements for longer-term, sound technical solutions; contribute to the process of finding the right longer-term solution.
4. 确定长期、可靠的技术解决方案的要求；有助于找到正确的长期解决方案。
A longer-term solution is already provided in [RFC5986]. However, that solution relies on widespread deployment. The UNSAF solution provided here is an interim solution that enables LIS access for Devices that are not able to benefit from deployment of the recommendations in [RFC5986].
[RFC5986]中已经提供了长期解决方案。然而，该解决方案依赖于广泛部署。此处提供的UNSAF解决方案是一个临时解决方案，可使无法从[RFC5986]中建议的部署中获益的设备能够访问LIS。
5. Discussion of the impact of the noted practical issues with existing deployed NATs and experience reports.
5. 与现有已部署NAT和经验报告讨论已注意到的实际问题的影响。
The UNSAF mechanism depends on the experience in deployment of STUN [RFC5389]. On the whole, existing residential gateway devices are able to provide access to STUN and DNS service reliably, although regard should be given to the size of the DNS response (see [RFC5625]).
UNSAF机制取决于STUN部署经验[RFC5389]。总的来说，现有的住宅网关设备能够可靠地提供对STUN和DNS服务的访问，但应考虑DNS响应的大小（参见[RFC5625]）。
Richard Barnes provided the text in Section 5.
Richard Barnes在第5节中提供了文本。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[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月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596]Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，RFC 3596，2003年10月。
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010.
[RFC5986]Thomson，M.和J.Winterbottom，“发现本地位置信息服务器（LIS）”，RFC 59862010年9月。
[RFC7105] Thomson, M. and J. Winterbottom, "Using Device-Provided Location-Related Measurements in Location Configuration Protocols", RFC 7105, January 2014.
[RFC7105]Thomson，M.和J.Winterbottom，“在位置配置协议中使用设备提供的位置相关测量”，RFC 7105，2014年1月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424]Daigle，L.和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
[RFC4848] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007.
[RFC4848]Daigle，L.，“使用URI和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 48482007年4月。
[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月。
[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月。
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010.
[RFC5687]Tschofenig，H.和H.Schulzrinne，“GEOPRIV第7层位置配置协议：问题陈述和要求”，RFC 5687，2010年3月。
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
[RFC6280]Barnes，R.，Lepinski，M.，Cooper，A.，Morris，J.，Tschofenig，H.，和H.Schulzrinne，“互联网应用中的位置和位置隐私架构”，BCP 160，RFC 62802011年7月。
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, July 2011.
[RFC6303]Andrews，M.，“本地服务DNS区域”，BCP 163，RFC 6303，2011年7月。
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.
[RFC6887]南柴郡Wing，D.，布卡达尔，M.，佩诺，R.，和P.Selkirk，“港口控制协议（PCP）”，RFC 6887，2013年4月。
[UPnP-IGD-WANIPConnection1] UPnP Forum, "Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0: WANIPConnection:1 Service Template Version 1.01 For UPnP Version 1.0", DCP 05-001, Nov. 2001, <http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v1-Service.pdf>.
[UPnP-IGD-WANIPConnection 1]UPnP论坛，“互联网网关设备（IGD）标准化设备控制协议V1.0:WANIPConnection:1服务模板版本1.01，适用于UPnP版本1.0”，DCP 05-001，2001年11月<http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v1-Service.pdf>。
[RFC6886] Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol (NAT-PMP)", RFC 6886, April 2013.
[RFC6886]Cheshire，S.和M.Krochmal，“NAT端口映射协议（NAT-PMP）”，RFC 68862013年4月。
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August 2009.
[RFC5625]Bellis，R.，“DNS代理实施指南”，BCP 152，RFC 56252009年8月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985]Barnes，M.，“支持HTTP的位置传递（保留）”，RFC 59852010年9月。
Authors' Addresses
作者地址
Martin Thomson Mozilla Suite 300 650 Castro Street Mountain View, CA 94041 US
美国加利福尼亚州山景城卡斯特罗街650号Martin Thomson Mozilla 300套房，邮编94041
EMail: martin.thomson@gmail.com
EMail: martin.thomson@gmail.com
Ray Bellis Nominet UK Edmund Halley Road Oxford OX4 4DQ United Kingdom
Ray Bellis Nominet UK Edmund Halley Road OX4 4DQ英国牛津大学
Phone: +44 1865 332211
EMail: ray.bellis@nominet.org.uk
URI: http://www.nominet.org.uk/
Phone: +44 1865 332211
EMail: ray.bellis@nominet.org.uk
URI: http://www.nominet.org.uk/