Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 5986 J. Winterbottom
Category: Standards Track Andrew Corporation
ISSN: 2070-1721 September 2010
Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 5986 J. Winterbottom
Category: Standards Track Andrew Corporation
ISSN: 2070-1721 September 2010
Discovering the Local Location Information Server (LIS)
发现本地位置信息服务器（LIS）
Abstract
摘要
Discovery of the correct Location Information Server (LIS) in the local access network is necessary for Devices that wish to acquire location information from the network. A method is described for the discovery of a LIS in the access network serving a Device. Dynamic Host Configuration Protocol (DHCP) options for IP versions 4 and 6 are defined that specify a domain name. This domain name is then used as input to a URI-enabled NAPTR (U-NAPTR) resolution process.
对于希望从网络获取位置信息的设备，需要在本地接入网络中发现正确的位置信息服务器（LIS）。描述了一种用于在服务于设备的接入网络中发现LIS的方法。定义了IP版本4和6的动态主机配置协议（DHCP）选项，用于指定域名。然后将此域名用作启用URI的NAPTR（U-NAPTR）解析过程的输入。
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/rfc5986.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5986.
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 and Overview . . . . . . . . . . . . . . . . . . 2
1.1. Discovery Procedure Overview . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. LIS Discovery Procedure . . . . . . . . . . . . . . . . . . . 4
2.1. Residential Gateways . . . . . . . . . . . . . . . . . . . 6
2.2. Virtual Private Networks (VPNs) . . . . . . . . . . . . . 7
3. Determining a Domain Name . . . . . . . . . . . . . . . . . . 7
3.1. Domain Name Encoding . . . . . . . . . . . . . . . . . . . 7
3.2. Access Network Domain Name DHCPv4 Option . . . . . . . . . 8
3.3. Access Network Domain Name DHCPv6 Option . . . . . . . . . 8
3.4. Alternative Domain Names . . . . . . . . . . . . . . . . . 9
4. U-NAPTR Resolution of a LIS URI . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6.1. Registration of DHCPv4 and DHCPv6 Option Codes . . . . . . 13
6.2. Registration of a Location Server Application Service
Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Registration of a Location Server Application Protocol
Tag for HELD . . . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
1.1. Discovery Procedure Overview . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. LIS Discovery Procedure . . . . . . . . . . . . . . . . . . . 4
2.1. Residential Gateways . . . . . . . . . . . . . . . . . . . 6
2.2. Virtual Private Networks (VPNs) . . . . . . . . . . . . . 7
3. Determining a Domain Name . . . . . . . . . . . . . . . . . . 7
3.1. Domain Name Encoding . . . . . . . . . . . . . . . . . . . 7
3.2. Access Network Domain Name DHCPv4 Option . . . . . . . . . 8
3.3. Access Network Domain Name DHCPv6 Option . . . . . . . . . 8
3.4. Alternative Domain Names . . . . . . . . . . . . . . . . . 9
4. U-NAPTR Resolution of a LIS URI . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6.1. Registration of DHCPv4 and DHCPv6 Option Codes . . . . . . 13
6.2. Registration of a Location Server Application Service
Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Registration of a Location Server Application Protocol
Tag for HELD . . . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
The location of a Device is a useful and sometimes necessary part of many services. A Location Information Server (LIS) is responsible for providing that location information to Devices with attached access networks used to provide Internet access. The LIS uses knowledge of the access network and its physical topology to generate and serve location information to Devices.
设备的位置是许多服务中有用且有时是必要的部分。位置信息服务器（LIS）负责将该位置信息提供给具有用于提供互联网接入的接入网络的设备。LIS使用接入网络及其物理拓扑的知识来生成位置信息并将其提供给设备。
Each access network requires specific knowledge about topology. Therefore, it is important to discover the LIS that has the specific knowledge necessary to locate a Device, that is, the LIS that serves the current access network. Automatic discovery is important where there is any chance of movement outside a single access network. Reliance on static configuration can lead to unexpected errors if a Device moves between access networks.
每个接入网络都需要特定的拓扑知识。因此，重要的是发现具有定位设备所需的特定知识的LIS，即服务于当前接入网络的LIS。当有可能在单个接入网络之外移动时，自动发现非常重要。如果设备在接入网络之间移动，依赖静态配置可能会导致意外错误。
This document describes a process that a Device can use to discover a LIS. This process uses a DHCP option and the DNS. The product of this discovery process is an HTTP [RFC2616] or HTTPS [RFC2818] URI that identifies a LIS.
本文档描述了设备可以用来发现LIS的过程。此进程使用DHCP选项和DNS。此发现过程的产物是标识LIS的HTTP[RFC2616]或HTTPS[RFC2818]URI。
The URI result from the discovery process is suitable for location configuration only; that is, the Device MUST dereference the URI using the process described in HTTP-Enabled Location Delivery (HELD) [RFC5985]. URIs discovered in this way are not "location URIs" [RFC5808]; dereferencing one of them provides the location of the requestor only. Devices MUST NOT embed these URIs in fields in other protocols designed to carry the location of the Device.
发现过程的URI结果仅适用于位置配置；也就是说，设备必须使用HTTP启用的位置传递（保持）[RFC5985]中描述的过程解除对URI的引用。以这种方式发现的URI不是“位置URI”[RFC5808]；取消引用其中一个只提供请求者的位置。设备不得将这些URI嵌入为承载设备位置而设计的其他协议的字段中。
DHCP ([RFC2131], [RFC3315]) is a commonly used mechanism for providing bootstrap configuration information that allows a Device to operate in a specific network environment. The DHCP information is largely static, consisting of configuration information that does not change over the period that the Device is attached to the network. Physical location information might change over this time; however, the address of the LIS does not. Thus, DHCP is suitable for configuring a Device with the address of a LIS.
DHCP（[RFC2131]、[RFC3315]）是一种常用的机制，用于提供引导配置信息，允许设备在特定网络环境中运行。DHCP信息基本上是静态的，包括在设备连接到网络期间不会改变的配置信息。物理位置信息可能会随时间变化；但是，LIS的地址没有。因此，DHCP适合配置具有LIS地址的设备。
This document defines a DHCP option that produces a domain name that identifies the local access network in Section 3.
本文档定义了一个DHCP选项，该选项生成一个域名，用于在第3节中标识本地访问网络。
Section 4 describes a method that uses URI-enabled NAPTR (U-NAPTR) [RFC4848], a Dynamic Delegation Discovery Service (DDDS) profile that produces a URI for the LIS. The input to this process is provided by the DHCP option.
第4节描述了一种使用启用URI的NAPTR（U-NAPTR）[RFC4848]的方法，该NAPTR是一种动态委派发现服务（DDDS）配置文件，用于为LIS生成URI。此过程的输入由DHCP选项提供。
For the LIS discovery DDDS application, an Application Service tag "LIS" and an Application Protocol tag "HELD" have been created and registered with the IANA. Based on the domain name, this U-NAPTR application uses the two tags to determine a URI for a LIS that supports the HELD protocol.
对于LIS discovery DDDS应用程序，已创建应用程序服务标签“LIS”和应用程序协议标签“HOLD”，并在IANA中注册。基于域名，此U-NAPTR应用程序使用这两个标记来确定支持HOLD协议的LIS的URI。
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 also uses the term "Device" to refer to an end host or client consistent with its use in HELD. In HELD and RFC 3693 [RFC3693] parlance, the Device is also the Target.
本文档还使用术语“设备”来指终端主机或客户端，该终端主机或客户端与其在存储中的使用一致。用Hold和RFC 3693[RFC3693]的说法，设备也是目标。
The term "access network" refers to the network to which a Device connects for Internet access. The "access network provider" is the entity that operates the access network. This is consistent with the definition in [RFC5687], which combines the Internet Access Provider
术语“接入网络”是指设备为接入互联网而连接到的网络。“接入网络提供商”是运营接入网络的实体。这与[RFC5687]中的定义一致，该定义结合了互联网接入提供商
(IAP) and Internet Service Provider (ISP). The access network provider is responsible for allocating the Device a public IP address and for directly or indirectly providing a LIS service.
（IAP）和互联网服务提供商（ISP）。接入网络提供商负责为设备分配公共IP地址，并直接或间接提供LIS服务。
A Device that has multiple network interfaces could potentially be served by a different access network on each interface, each with a different LIS. The Device SHOULD attempt to discover the LIS applicable to each network interface, stopping when a LIS is successfully discovered on any interface.
具有多个网络接口的设备可能由每个接口上的不同接入网络提供服务，每个接口都具有不同的LIS。设备应尝试发现适用于每个网络接口的LIS，并在任何接口上成功发现LIS时停止。
The LIS discovery procedure follows this process:
LIS发现过程遵循以下过程：
1. Acquire the access network domain name (Section 3).
1. 获取接入网域名（第3节）。
This process might be repeated for each of the network interfaces on the Device. Domain names acquired from other sources might also be added.
此过程可能会对设备上的每个网络接口重复。也可以添加从其他来源获取的域名。
2. Apply U-NAPTR resolution (Section 4) to discover a LIS URI.
2. 应用U-NAPTR解析（第4节）来发现LIS URI。
The U-NAPTR process is applied using each of the domain names as input.
U-NAPTR过程使用每个域名作为输入。
3. Verify that the LIS is able to provide location information.
3. 验证LIS是否能够提供位置信息。
The first URI that results in a successful response from the LIS is used.
使用导致来自LIS的成功响应的第一个URI。
A Device MUST support discovery using the access network domain name DHCP option (Section 3) as input to U-NAPTR resolution (Section 4). If this option is not available, DHCPv4 option 15 [RFC2132] is used. Other domain names MAY be used, as described in Section 3.4.
设备必须支持使用访问网络域名DHCP选项（第3节）作为U-NAPTR解析（第4节）的输入进行发现。如果此选项不可用，则使用DHCPv4选项15[RFC2132]。如第3.4节所述，可使用其他域名。
A Device that discovers a LIS URI MUST attempt to verify that the LIS is able to provide location information. For the HELD protocol, the Device verifies the URI by making a location request to the LIS. Any HTTP 200 response containing a HELD response signifies success. This includes HELD error responses, with the exception of the "notLocatable" error.
发现LIS URI的设备必须尝试验证LIS是否能够提供位置信息。对于HOLD协议，设备通过向LIS发出位置请求来验证URI。任何包含保留响应的HTTP 200响应都表示成功。这包括保留的错误响应，但“notLocatable”错误除外。
If -- at any time -- the LIS responds to a request with the "notLocatable" error code (see Section 4.3.2 of [RFC5985]), the Device MUST continue or restart the discovery process. A Device SHOULD NOT make further requests to a LIS that provides a "notLocatable" error until its network attachment changes, or it discovers the LIS on an alternative network interface.
如果在任何时候，LIS以“notLocatable”错误代码响应请求（见[RFC5985]第4.3.2节），则设备必须继续或重新启动发现过程。设备在其网络连接发生变化或在替代网络接口上发现LIS之前，不应向提供“notLocatable”错误的LIS发出进一步请求。
Static configuration of a domain name or a LIS URI MAY be used. Note that if a Device has moved from its customary location, static configuration might indicate a LIS that is unable to provide accurate location information.
可以使用域名或LIS URI的静态配置。请注意，如果设备已从其常规位置移动，静态配置可能表示LIS无法提供准确的位置信息。
The product of the LIS discovery process for HELD is an HTTPS or HTTP URI. Nothing distinguishes this URI from other URIs with the same scheme, aside from the fact that it is the product of this process. Only URIs produced by the discovery process can be used for location configuration using HELD.
HOLD的LIS发现过程的产物是HTTPS或HTTP URI。除了它是这个过程的产物这一事实之外，这个URI与具有相同方案的其他URI没有任何区别。只有发现过程生成的URI才能使用HOLD进行位置配置。
The overall discovery process is summarized in Figure 1.
图1总结了整个发现过程。
-----------
( Start )
-----+-----
|<--------------------------------------+
| |
V |
------^------- ------^------ |
/ \ / 1. \ |
< Next interface >------->< Get domain >-----+
\ / Y ^ \ / N
------v------- | ------v------
| N | | Y
| | V
| | ------^------
| | / 2. \
| +----< Get URI ><----+
| N \ / |
| ------v------ |
| | Y |
| V |
| ------^------ |
| / 3. \ |
| < Check URI >-----+
| \ / N
| ------v------
| | Y
V V
----------- -----------
( Failure ) ( Success )
----------- -----------
-----------
( Start )
-----+-----
|<--------------------------------------+
| |
V |
------^------- ------^------ |
/ \ / 1. \ |
< Next interface >------->< Get domain >-----+
\ / Y ^ \ / N
------v------- | ------v------
| N | | Y
| | V
| | ------^------
| | / 2. \
| +----< Get URI ><----+
| N \ / |
| ------v------ |
| | Y |
| V |
| ------^------ |
| / 3. \ |
| < Check URI >-----+
| \ / N
| ------v------
| | Y
V V
----------- -----------
( Failure ) ( Success )
----------- -----------
Figure 1: LIS Discovery Flowchart
图1:LIS发现流程图
The options available in residential gateways will affect the success of this algorithm in residential network scenarios. A fixed wireline scenario is described in more detail in [RFC5687], Section 3.1. In this fixed wireline environment, an intervening residential gateway exists between the Device and the access network. If the residential gateway does not provide the appropriate information to the Devices it serves, those Devices are unable to discover a LIS.
住宅网关中可用的选项将影响该算法在住宅网络场景中的成功。[RFC5687]第3.1节详细描述了固定电缆方案。在这种固定有线环境中，设备和接入网络之间存在一个介入的住宅网关。如果住宅网关未向其服务的设备提供适当的信息，则这些设备无法发现LIS。
Support of this specification by residential gateways ensures that the Devices they serve are able to acquire location information. In many cases, the residential gateway configures the Devices it serves using DHCP. A residential gateway is able to use DHCP to assist Devices in gaining access to their location information. This can be accomplished by providing an access network domain name DHCP option suitable for LIS discovery, or by acting as a LIS directly. To actively assist Devices, a residential gateway can either:
住宅网关对本规范的支持可确保其服务的设备能够获取位置信息。在许多情况下，住宅网关使用DHCP配置其服务的设备。住宅网关能够使用DHCP帮助设备访问其位置信息。这可以通过提供适合LIS发现的访问网络域名DHCP选项或直接充当LIS来实现。为了主动协助设备，住宅网关可以：
o acquire an access network domain name from the access network provider (possibly using DHCP) and pass the resulting value to Devices; or
o 从接入网络提供商处获取接入网络域名（可能使用DHCP），并将结果值传递给设备；或
o discover a LIS on its external interface, then provide Devices with the domain name that was used to successfully discover the LIS; or
o 在外部接口上发现LIS，然后向设备提供用于成功发现LIS的域名；或
o explicitly include configuration that refers to a particular LIS; or
o 明确包括引用特定LIS的配置；或
o act as a LIS and directly provide location information to the Devices it serves, including providing a means to discover this service.
o 充当LIS并直接向其服务的设备提供位置信息，包括提供发现此服务的方法。
As with Devices, configuration of a specific domain name or location information is only accurate as long as the residential gateway does not move. If a residential gateway that relies on configuration rather than automatic discovery is moved, the Devices it serves could be provided with inaccurate information. Devices could be led to discover a LIS that is unable to provide accurate location information, or -- if location is configured on the residential gateway -- the residential gateway could provide incorrect location information.
与设备一样，只有在住宅网关不移动的情况下，特定域名或位置信息的配置才是准确的。如果移动依赖于配置而非自动发现的住宅网关，则可能会向其服务的设备提供不准确的信息。设备可能会被引导发现无法提供准确位置信息的LIS，或者——如果在住宅网关上配置了位置——住宅网关可能会提供不正确的位置信息。
A Device MUST NOT attempt LIS discovery over a VPN network interface until it has attempted and failed to perform discovery on all other non-VPN interfaces. A Device MAY perform discovery over a VPN network interface if it has first attempted discovery on non-VPN interfaces, but a LIS discovered in this way is unlikely to have the information necessary to determine an accurate location.
在尝试在所有其他非VPN接口上执行发现且失败之前，设备不得尝试通过VPN网络接口进行LIS发现。如果设备首次尝试在非VPN接口上进行发现，则可以通过VPN网络接口执行发现，但以这种方式发现的LIS不太可能具有确定准确位置所需的信息。
Not all interfaces connected to a VPN can be detected by Devices or the software running on them. In these cases, it might be that a LIS on the remote side of a VPN is inadvertently discovered. A LIS provides a "notLocatable" error code in response to a request that it is unable to fulfill (see [RFC5985], Section 6.3). This ensures that even if a Device discovers a LIS over the VPN, it does not rely on a LIS that is unable to provide accurate location information.
并非所有连接到VPN的接口都能被设备或其上运行的软件检测到。在这些情况下，可能会无意中发现VPN远程端的LIS。LIS提供“notLocatable”错误代码，以响应其无法满足的请求（参见[RFC5985]，第6.3节）。这确保即使设备通过VPN发现LIS，也不会依赖无法提供准确位置信息的LIS。
DHCP provides a direct means for the access network provider to configure a Device. The access network domain name option identifies a domain name that is suitable for service discovery within the access network. This domain name is used as input to the U-NAPTR resolution process for LIS discovery.
DHCP为接入网络提供商提供了配置设备的直接方法。“接入网络域名”选项标识适合于接入网络内服务发现的域名。此域名用作LIS发现U-NAPTR解析过程的输入。
The domain name provided in this option is one owned by the access network operator. This domain name is intended for use in discovering services within the access network.
此选项中提供的域名为接入网络运营商所有。此域名用于发现接入网络中的服务。
This document registers a DHCP option for the access network domain name for both IPv4 and IPv6.
本文档为IPv4和IPv6的访问网络域名注册DHCP选项。
This section describes the encoding of the domain name used in the DHCPv4 option defined in Section 3.2 and also used in the DHCPv6 option defined in Section 3.3.
本节介绍第3.2节定义的DHCPv4选项中使用的域名编码，以及第3.3节定义的DHCPv6选项中使用的域名编码。
The domain name is encoded according to Section 3.1 of [RFC1035]. Each label is represented as a one-octet length field followed by that number of octets. Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of zero. The high-order two bits of every length octet MUST be zero, and the remaining six bits of the length field limit the label to 63 octets or less. To simplify implementations, the total length of a domain name (i.e., label octets and label length octets) is restricted to 255 octets or less.
域名按照[RFC1035]第3.1节进行编码。每个标签表示为一个八位字节长度字段，后跟该八位字节数。由于每个域名都以根的空标签结尾，因此域名以长度为零的字节结尾。每个长度八位字节的高阶两位必须为零，长度字段的其余六位将标签限制为63个八位字节或更少。为了简化实现，域名的总长度（即标签八位字节和标签长度八位字节）限制为255个八位字节或更少。
For example, the domain "example.com." is encoded in 13 octets as:
例如，域“example.com.”以13个八位字节编码为：
+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 7 | e | x | a | m | p | l | e | 3 | c | o | m | 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 7 | e | x | a | m | p | l | e | 3 | c | o | m | 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+
Note that the length field in either option represents the length of the entire domain name encoding, whereas the length fields in the domain name encoding is the length of a single domain name label.
请注意，任一选项中的长度字段表示整个域名编码的长度，而域名编码中的长度字段是单个域名标签的长度。
This section defines a DHCP for IPv4 (DHCPv4) option for the domain name associated with the access network.
本节为与访问网络关联的域名定义了DHCP for IPv4（DHCPv4）选项。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Access Network Domain Name .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Access Network Domain Name (cont.) .
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Access Network Domain Name .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Access Network Domain Name (cont.) .
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Access Network Domain Name DHCPv4 Option
图2：访问网络域名DHCPv4选项
option-code: OPTION_V4_ACCESS_DOMAIN (213).
选项代码：选项4访问域（213）。
option-length: The length of the entire access network domain name option in octets.
option length：整个接入网络域名选项的长度（以八位字节为单位）。
option-value: The domain name associated with the access network, encoded as described in Section 3.1.
选项值：与接入网络相关的域名，编码如第3.1节所述。
A DHCPv4 client MAY request an access network domain name option in a Parameter Request List option, as described in [RFC2131].
如[RFC2131]所述，DHCPv4客户端可以在参数请求列表选项中请求访问网络域名选项。
This option contains a single domain name and, as such, MUST contain precisely one root label.
此选项包含单个域名，因此必须仅包含一个根标签。
This section defines a DHCP for IPv6 (DHCPv6) option for the domain name associated with the access network. The DHCPv6 option for this parameter is similarly formatted to the DHCPv4 option.
本节为与访问网络关联的域名定义了DHCP for IPv6（DHCPv6）选项。此参数的DHCPv6选项的格式与DHCPv4选项的格式类似。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V6_ACCESS_DOMAIN | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Access Network Domain Name .
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V6_ACCESS_DOMAIN | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Access Network Domain Name .
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DHCPv6 Access Network Domain Name Option
图3:DHCPv6访问网络域名选项
option-code: OPTION_V6_ACCESS_DOMAIN (57).
选项代码：选项访问域（57）。
option-length: The length of the entire access network domain name option in octets.
option length：整个接入网络域名选项的长度（以八位字节为单位）。
option-value: The domain name associated with the access network, encoded as described in Section 3.1.
选项值：与接入网络相关的域名，编码如第3.1节所述。
A DHCPv6 client MAY request an access network domain name option in an Options Request Option (ORO), as described in [RFC3315].
DHCPv6客户端可以在选项请求选项（ORO）中请求访问网络域名选项，如[RFC3315]中所述。
This option contains a single domain name and, as such, MUST contain precisely one root label.
此选项包含单个域名，因此必须仅包含一个根标签。
The U-NAPTR resolution method described requires a domain name as input. The access network domain name DHCP options (Sections 3.2 and 3.3) are one source of this domain name.
所述的U-NAPTR解析方法需要域名作为输入。访问网络域名DHCP选项（第3.2节和第3.3节）是该域名的来源之一。
If a Device knows one or more alternative domain names that might be used for discovery, it MAY repeat the U-NAPTR process using those domain names as input. For instance, static configuration of a Device might be used to provide a Device with a domain name.
如果设备知道可能用于发现的一个或多个备选域名，则可以使用这些域名作为输入重复U-NAPTR过程。例如，可以使用设备的静态配置为设备提供域名。
DHCPv4 option 15 [RFC2132] provides an indication of the domain name that a host uses when resolving hostnames in DNS. This option is used when the DHCPv4 access domain name is not available.
DHCPv4选项15[RFC2132]提供主机在DNS中解析主机名时使用的域名指示。当DHCPv4访问域名不可用时，使用此选项。
DHCPv4 option 15 might not be suitable for some network deployments. For instance, a global enterprise could operate multiple sites, with Devices at all sites using the same value for option 15. In this type of deployment, it might be desirable to discover a LIS local to a site. The access domain name option can be given a different value at each site to enable discovery of a LIS at that site.
DHCPv4选项15可能不适用于某些网络部署。例如，一家全球企业可以运营多个站点，所有站点的设备都使用选项15的相同值。在这种类型的部署中，可能需要发现站点的本地LIS。可以在每个站点为“访问域名”选项指定不同的值，以便在该站点发现LIS。
Alternative domain names MUST NOT be used unless the access network domain name option is unsuccessful or where external information indicates that a particular domain name is to be used.
除非访问网络域名选项不成功或外部信息表明要使用特定域名，否则不得使用替代域名。
Other domain names might be provided by a DHCP server (for example, [RFC4702] for DHCPv4, [RFC4704] for DHCPv6). However, these domain names could be provided without considering their use for LIS discovery; therefore, it is not likely that these other domain names contain useful values.
其他域名可能由DHCP服务器提供（例如，[RFC4702]用于DHCPv4，[RFC4704]用于DHCPv6）。但是，可以提供这些域名，而不考虑将其用于LIS发现；因此，这些其他域名不太可能包含有用的值。
U-NAPTR [RFC4848] resolution for a LIS takes a domain name as input and produces a URI that identifies the LIS. This process also requires an Application Service tag and an Application Protocol tag, which differentiate LIS-related NAPTR records from other records for that domain.
LIS的U-NAPTR[RFC4848]解析将域名作为输入，并生成标识LIS的URI。此过程还需要一个应用程序服务标签和一个应用程序协议标签，用于区分与LIS相关的NAPTR记录与该域的其他记录。
Section 6.2 defines an Application Service tag of "LIS", which is used to identify the location service for a given domain. The Application Protocol tag "HELD", defined in Section 6.3, is used to identify a LIS that understands the HELD protocol [RFC5985].
第6.2节定义了应用程序服务标签“LIS”，用于标识给定域的位置服务。第6.3节中定义的应用协议标签“HOLD”用于识别理解HOLD协议的LIS[RFC5985]。
The NAPTR records in the following example demonstrate the use of the Application Service and Protocol tags. Iterative NAPTR resolution is used to delegate responsibility for the LIS service from "zonea.example.net." and "zoneb.example.net." to "outsource.example.com.".
下面示例中的NAPTR记录演示了应用程序服务和协议标记的使用。迭代NAPTR解析用于将LIS服务的责任从“zonea.example.net.”和“zoneb.example.net.”委派给“outsource.example.com.”。
zonea.example.net.
;; order pref flags
IN NAPTR 100 10 "" "LIS:HELD" ( ; service
"" ; regex
outsource.example.com. ; replacement
)
zoneb.example.net.
;; order pref flags
IN NAPTR 100 10 "" "LIS:HELD" ( ; service
"" ; regex
outsource.example.com. ; replacement
)
outsource.example.com.
;; order pref flags
IN NAPTR 100 10 "u" "LIS:HELD" ( ; service
"!.*!https://lis.example.org:4802/?c=ex!" ; regex
. ; replacement
)
zonea.example.net.
;; order pref flags
IN NAPTR 100 10 "" "LIS:HELD" ( ; service
"" ; regex
outsource.example.com. ; replacement
)
zoneb.example.net.
;; order pref flags
IN NAPTR 100 10 "" "LIS:HELD" ( ; service
"" ; regex
outsource.example.com. ; replacement
)
outsource.example.com.
;; order pref flags
IN NAPTR 100 10 "u" "LIS:HELD" ( ; service
"!.*!https://lis.example.org:4802/?c=ex!" ; regex
. ; replacement
)
Figure 4: Sample LIS:HELD Service NAPTR Records
图4：示例LIS：保留的服务NAPTR记录
Details for the "LIS" Application Service tag and the "HELD" Application Protocol tag are included in Section 6.
“LIS”应用程序服务标签和“保持”应用程序协议标签的详细信息包含在第6节中。
U-NAPTR resolution might produce multiple results from each iteration of the algorithm. Order and preference values in the NAPTR record determine which value is chosen. A Device MAY attempt to use alternative choices if the first choice is not successful. However, if a request to the resulting URI produces a HELD "notLocatable" response, or equivalent, the Device SHOULD NOT attempt to use any alternative choices from the same domain name.
U-NAPTR resolution might produce multiple results from each iteration of the algorithm. Order and preference values in the NAPTR record determine which value is chosen. A Device MAY attempt to use alternative choices if the first choice is not successful. However, if a request to the resulting URI produces a HELD "notLocatable" response, or equivalent, the Device SHOULD NOT attempt to use any alternative choices from the same domain name.translate error, please retry
An HTTPS LIS URI that is a product of U-NAPTR MUST be authenticated using the domain name method described in Section 3.1 of RFC 2818 [RFC2818]. The domain name that is used in this authentication is the one extracted from the URI, not the one that was input to the U-NAPTR resolution process.
U-NAPTR产品的HTTPS LIS URI必须使用RFC 2818[RFC2818]第3.1节中描述的域名方法进行身份验证。此身份验证中使用的域名是从URI提取的域名，而不是输入到U-NAPTR解析过程的域名。
The address of a LIS is usually well-known within an access network; therefore, interception of messages does not introduce any specific concerns.
LIS的地址通常在接入网络中是众所周知的；因此，截取消息不会引起任何具体问题。
The primary attack against the methods described in this document is one that would lead to impersonation of a LIS. The LIS is responsible for providing location information, and this information is critical to a number of network services; furthermore, a Device
针对本文档中描述的方法的主要攻击会导致模拟LIS。LIS负责提供位置信息，该信息对许多网络服务至关重要；此外，一种装置
does not necessarily have a prior relationship with a LIS. Several methods are described here that can limit the probability of, or provide some protection against, such an attack. These methods MUST be applied unless similar protections are in place, or in cases -- such as an emergency -- where location information of dubious origin is arguably better than none at all.
不一定与LIS有优先关系。这里描述了几种方法，这些方法可以限制此类攻击的概率，或者提供一些保护以防止此类攻击。除非有类似的保护措施，或者在诸如紧急情况之类的情况下，来源可疑的位置信息可以说比没有更好，否则必须采用这些方法。
An attacker could attempt to compromise LIS discovery at any of three stages:
攻击者可以在以下三个阶段中的任意一个阶段尝试破坏LIS发现：
1. providing a falsified domain name to be used as input to U-NAPTR
1. 提供伪造域名作为U-NAPTR的输入
2. altering the DNS records used in U-NAPTR resolution
2. 更改U-NAPTR解析中使用的DNS记录
3. impersonating the LIS
3. 模拟LIS
The domain name that used to authenticate the LIS is the domain name input to the U-NAPTR process, not the output of that process [RFC3958], [RFC4848]. As a result, the results of DNS queries do not need integrity protection.
用于验证LIS的域名是U-NAPTR进程的域名输入，而不是该进程的输出[RFC3958]、[RFC4848]。因此，DNS查询的结果不需要完整性保护。
An HTTPS URI is authenticated using the method described in Section 3.1 of [RFC2818]. HTTP client implementations frequently do not provide a means to authenticate based on a domain name other than the one indicated in the request URI, namely the U-NAPTR output. To avoid having to authenticate the LIS with a domain name that is different from the one used to identify it, a client MAY choose to reject URIs that contain a domain name that is different to the U-NAPTR input. To support endpoints that enforce the above restriction on URIs, network administrators SHOULD ensure that the domain name in the DHCP option is the same as the one contained in the resulting URI.
HTTPS URI使用[RFC2818]第3.1节中描述的方法进行身份验证。HTTP客户端实现通常不提供基于请求URI中指示的域名以外的域名（即U-NAPTR输出）进行身份验证的方法。为了避免必须使用不同于用于标识的域名对LIS进行身份验证，客户机可以选择拒绝包含不同于U-NAPTR输入的域名的URI。为了支持对URI实施上述限制的端点，网络管理员应确保DHCP选项中的域名与结果URI中包含的域名相同。
Authentication of a LIS relies on the integrity of the domain name acquired from DHCP. An attacker that is able to falsify a domain name circumvents the protections provided. To ensure that the access network domain name DHCP option can be relied upon, preventing DHCP messages from being modified or spoofed by attackers is necessary. Physical- or link-layer security are commonly used to reduce the possibility of such an attack within an access network. DHCP authentication [RFC3118] might also provide a degree of protection against modification or spoofing.
LIS的身份验证依赖于从DHCP获取的域名的完整性。能够伪造域名的攻击者可以绕过提供的保护。为了确保访问网络域名DHCP选项可以被依赖，有必要防止攻击者修改或欺骗DHCP消息。物理层或链路层安全通常用于降低接入网络中发生此类攻击的可能性。DHCP身份验证[RFC3118]还可以提供一定程度的保护，防止修改或欺骗。
A LIS that is identified by an HTTP URI cannot be authenticated. Use of unsecured HTTP also does not meet requirements in HELD for confidentiality and integrity. If an HTTP URI is the product of LIS
无法对由HTTP URI标识的LIS进行身份验证。使用不安全的HTTP也不符合HOLD中的保密性和完整性要求。如果HTTP URI是LIS的产物
discovery, this leaves Devices vulnerable to several attacks. Lower-layer protections, such as Layer 2 traffic separation might be used to provide some guarantees.
发现时，这使设备容易受到多种攻击。较低层的保护，如第2层交通隔离，可用于提供一些保障。
The IANA has assigned an option code of 213 for the DHCPv4 option for an access network domain name option, as described in Section 3.2 of this document.
IANA已为接入网络域名选项的DHCPv4选项分配了选项代码213，如本文件第3.2节所述。
The IANA has assigned an option code of 57 for the DHCPv6 option for an access network domain name option, as described in Section 3.3 of this document.
IANA已为接入网络域名选项的DHCPv6选项分配了选项代码57，如本文件第3.3节所述。
This section registers a new S-NAPTR/U-NAPTR Application Service tag for LIS, as mandated by [RFC3958].
本节按照[RFC3958]的要求，为LIS注册一个新的S-NAPTR/U-NAPTR应用程序服务标签。
Application Service Tag: LIS
应用服务标签：LIS
Intended usage: Identifies a service that provides a Device with its location information.
预期用途：标识为设备提供位置信息的服务。
Defining publication: RFC 5986
定义发布：RFC 5986
Related publications: HELD [RFC5985]
相关出版物：持有[RFC5985]
Contact information: The authors of this document
联系方式：本文件的作者
Author/Change controller: The IESG
作者/变更控制员：IESG
6.3. Registration of a Location Server Application Protocol Tag for HELD
6.3. 为保留的注册位置服务器应用程序协议标记
This section registers a new S-NAPTR/U-NAPTR Application Protocol tag for the HELD protocol [RFC5985], as mandated by [RFC3958].
本节根据[RFC3958]的规定，为保留协议[RFC5985]注册新的S-NAPTR/U-NAPTR应用协议标签。
Application Protocol Tag: HELD
应用程序协议标签：保留
Intended Usage: Identifies the HELD protocol.
预期用途：标识保留的协议。
Applicable Service Tag(s): LIS
适用的服务标签：LIS
Terminal NAPTR Record Type(s): U
终端NAPTR记录类型：U
Defining Publication: RFC 5986
定义发布：RFC 5986
Related Publications: HELD [RFC5985]
相关出版物：持有[RFC5985]
Contact Information: The authors of this document
联系方式：本文件的作者
Author/Change Controller: The IESG
作者/变更控制员：IESG
This document uses a mechanism that is largely identical to that in [RFC5222] and [RFC5223]. The authors would like to thank Leslie Daigle for her work on U-NAPTR; Peter Koch for feedback on how not to use DNS for discovery; Andy Newton for constructive suggestions with regards to document direction; Richard Barnes, Joe Salowey, Barbara Stark, and Hannes Tschofenig for input and reviews; and Dean Willis for constructive feedback.
本文件使用的机制与[RFC5222]和[RFC5223]中的机制基本相同。作者要感谢Leslie Daigle在U-NAPTR方面的工作；Peter Koch提供了关于如何不使用DNS进行发现的反馈；Andy Newton就文件方向提出建设性建议；Richard Barnes、Joe Salowey、Barbara Stark和Hannes Tschofenig提供意见和评论；和迪安·威利斯的建设性反馈。
[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月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[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月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option", RFC 4702, October 2006.
[RFC4702]Stapp，M.，Volz，B.，和Y.Rekhter，“动态主机配置协议（DHCP）客户端完全限定域名（FQDN）选项”，RFC 4702，2006年10月。
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, October 2006.
[RFC4704]Volz，B.，“IPv6（DHCPv6）客户端完全限定域名（FQDN）选项的动态主机配置协议”，RFC 4704，2006年10月。
[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月。
[RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985]巴恩斯，M.，编辑，“支持HTTP的位置传递（保留）”，RFC 59852010年9月。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118]Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693]Cuellar，J.，Morris，J.，Mulligan，D.，Peterson，J.，和J.Polk，“地质驱动要求”，RFC 3693，2004年2月。
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3958]Daigle，L.和A.Newton，“使用SRV RRs和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 3958，2005年1月。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.
[RFC5222]Hardie，T.，Newton，A.，Schulzrinne，H.，和H.Tschofenig，“丢失：位置到服务转换协议”，RFC 5222，2008年8月。
[RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)", RFC 5223, August 2008.
[RFC5223]Schulzrinne，H.，Polk，J.，和H.Tschofenig，“使用动态主机配置协议（DHCP）发现位置到服务转换（丢失）服务器”，RFC 52232008年8月。
[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月。
[RFC5808] Marshall, R., "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010.
[RFC5808]Marshall，R.，“通过参考机制定位的要求”，RFC 5808，2010年5月。
Authors' Addresses
作者地址
Martin Thomson Andrew Corporation Andrew Building (39) Wollongong University Campus Northfields Avenue Wollongong, NSW 2522 AU
马丁·汤姆森·安德鲁公司安德鲁大厦（39）卧龙岗大学校园北田大道卧龙岗，新南威尔士州2522
Phone: +61 2 4221 2915
EMail: martin.thomson@andrew.com
Phone: +61 2 4221 2915
EMail: martin.thomson@andrew.com
James Winterbottom Andrew Corporation Andrew Building (39) Wollongong University Campus Northfields Avenue Wollongong, NSW 2522 AU
James Winterbottom Andrew Corporation Andrew Building（39）卧龙岗大学校园北田大道，新南威尔士州卧龙岗2522 AU
Phone: +61 2 4221 2938
EMail: james.winterbottom@andrew.com
Phone: +61 2 4221 2938
EMail: james.winterbottom@andrew.com