Network Working Group H. Schulzrinne
Request for Comments: 5223 Columbia University
Category: Standards Track J. Polk
Cisco
H. Tschofenig
Nokia Siemens Networks
August 2008
Network Working Group H. Schulzrinne
Request for Comments: 5223 Columbia University
Category: Standards Track J. Polk
Cisco
H. Tschofenig
Nokia Siemens Networks
August 2008
Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)
使用动态主机配置协议（DHCP）发现位置到服务转换（丢失）服务器
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
The Location-to-Service Translation (LoST) Protocol describes an XML-based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere, but a placement closer to the end host, e.g., in the access network, is desirable. In disaster situations with intermittent network connectivity, such a LoST server placement provides benefits regarding the resiliency of emergency service communication.
位置到服务转换（LoST）协议描述了一种基于XML的协议，用于将服务标识符和地理空间或城市位置信息映射到服务联系人统一资源定位器（URL）。丢失的服务器可以位于任何位置，但需要靠近终端主机的位置，例如在接入网络中。在具有间歇性网络连接的灾难情况下，这种丢失的服务器位置有利于紧急服务通信的恢复能力。
This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP).
本文档描述丢失的客户端如何使用动态主机配置协议（DHCP）发现丢失的服务器。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Domain Name Encoding . . . . . . . . . . . . . . . . . . . . . 3
4. LoST Server DHCPv4 Option . . . . . . . . . . . . . . . . . . . 3
5. LoST Server DHCPv6 Option . . . . . . . . . . . . . . . . . . . 4
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7.1. DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . . . 5
7.2. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . . 6
10.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Domain Name Encoding . . . . . . . . . . . . . . . . . . . . . 3
4. LoST Server DHCPv4 Option . . . . . . . . . . . . . . . . . . . 3
5. LoST Server DHCPv6 Option . . . . . . . . . . . . . . . . . . . 4
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7.1. DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . . . 5
7.2. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . . 6
10.2. Informative References . . . . . . . . . . . . . . . . . . 6
The Location-to-Service Translation (LoST) Protocol [RFC5222] describes an XML-based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs).
位置到服务转换（LoST）协议[RFC5222]描述了一种基于XML的协议，用于将服务标识符和地理空间或城市位置信息映射到服务联系人统一资源定位器（URL）。
In order to interact with a LoST server, the LoST client needs to discover the server's IP address. Several mechanisms can be used to learn this address, including manual configuration. In environments where the access network itself either deploys a LoST server or knows a third party that operates a LoST server, DHCP can provide the end host with a domain name. This domain name is then used as input to the DNS-based resolution mechanism described in LoST [RFC5222] that reuses the URI-enabled NAPTR specification (see [RFC4848]).
为了与丢失的服务器交互，丢失的客户端需要发现服务器的IP地址。可以使用多种机制来了解此地址，包括手动配置。在接入网络本身部署丢失服务器或知道第三方操作丢失服务器的环境中，DHCP可以向终端主机提供域名。然后将该域名用作LoST[RFC5222]中描述的基于DNS的解析机制的输入，该解析机制重用启用URI的NAPTR规范（请参见[RFC4848]）。
This document specifies a DHCPv4 and a DHCPv6 option that allows LoST clients to discover local LoST servers.
本文档指定了一个DHCPv4和一个DHCPv6选项，该选项允许丢失的客户端发现本地丢失的服务器。
Section 2 provides terminology. Section 3 shows the encoding of the domain name. Section 4 describes the DHCPv4 option while Section 5 describes the DHCPv6 option, with the same functionality. IANA and Security Considerations complete the document in Sections 7 and 8.
第2节提供了术语。第3节显示了域名的编码。第4节描述了DHCPv4选项，而第5节描述了具有相同功能的DHCPv6选项。IANA和安全考虑完成了第7节和第8节中的文件。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
Within this document, we use terminology from [RFC5012] and [RFC5222].
在本文件中，我们使用[RFC5012]和[RFC5222]中的术语。
This section describes the encoding of the domain name used in the DHCPv4 option shown in Section 4 and also used in the DHCPv6 option shown in Section 5.
本节介绍第4节所示DHCPv4选项中使用的域名编码，以及第5节所示DHCPv6选项中使用的域名编码。
The domain name is encoded according to Section 3.1 of RFC 1035 [RFC1035] whereby 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.
域名根据RFC 1035[RFC1035]第3.1节进行编码，其中每个标签表示为一个八位字节长度字段，后跟该八位字节数。由于每个域名都以根的空标签结尾，因此域名以长度为零的字节结尾。每个长度八位字节的高阶两位必须为零，长度字段的其余六位将标签限制为63个八位字节或更少。为了简化实现，域名的总长度（即标签八位字节和标签长度八位字节）限制为255个八位字节或更少。
The LoST server DHCPv4 option carries a DNS (RFC 1035 [RFC1035]) fully-qualified domain name (FQDN) to be used by the LoST client to locate a LoST server.
丢失的服务器DHCPv4选项包含一个DNS（RFC 1035[RFC1035]）完全限定域名（FQDN），丢失的客户端将使用该域名定位丢失的服务器。
The DHCP option for this encoding has the following format:
此编码的DHCP选项具有以下格式：
Code Len LoST Server Domain Name
+-----+-----+-----+-----+-----+-----+-----+----
| 137 | n | s1 | s2 | s3 | s4 | s5 | ...
+-----+-----+-----+-----+-----+-----+-----+----
Code Len LoST Server Domain Name
+-----+-----+-----+-----+-----+-----+-----+----
| 137 | n | s1 | s2 | s3 | s4 | s5 | ...
+-----+-----+-----+-----+-----+-----+-----+----
Figure 1: LoST FQDN DHCPv4 Option
图1：丢失的FQDN DHCPv4选项
The values s1, s2, s3, etc. represent the domain name labels in the domain name encoding. Note that the length field in the DHCPv4 option represents the length of the entire domain name encoding, whereas the length fields in the domain name encoding (see Section 3) is the length of a single domain name label.
值s1、s2、s3等表示域名编码中的域名标签。请注意，DHCPv4选项中的长度字段表示整个域名编码的长度，而域名编码中的长度字段（参见第3节）是单个域名标签的长度。
Code: OPTION_V4_LOST (137)
代码：选项4丢失（137）
Len: Length of the 'LoST Server Domain Name' field in octets; variable.
Len：“丢失的服务器域名”字段的长度（以八位字节为单位）；变量
LoST Server Domain Name: The domain name of the LoST server for the client to use.
丢失服务器域名：客户端要使用的丢失服务器的域名。
A DHCPv4 client MAY request a LoST server domain name in a Parameter Request List option, as described in [RFC2131].
DHCPv4客户端可以在参数请求列表选项中请求丢失的服务器域名，如[RFC2131]中所述。
The encoding of the domain name is described in Section 3.
第3节描述了域名的编码。
This option contains a single domain name and, as such, MUST contain precisely one root label.
此选项包含单个域名，因此必须仅包含一个根标签。
This section defines a DHCPv6 option to carry a domain name.
本节定义了一个DHCPv6选项来携带域名。
The DHCPv6 option has the format shown in Figure 2.
DHCPv6选项的格式如图2所示。
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_LOST | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LoST Server 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_LOST | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LoST Server Domain Name |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_V6_LOST (51)
选项代码：选项6丢失（51）
option-length: Length of the 'LoST Server Domain Name' field in octets; variable.
选项长度：“丢失的服务器域名”字段的长度（以八位字节为单位）；变量
LoST Server Domain Name: The domain name of the LoST server for the client to use.
丢失服务器域名：客户端要使用的丢失服务器的域名。
Figure 2: DHCPv6 Option for LoST Server Domain Name List
图2：丢失服务器域名列表的DHCPv6选项
A DHCPv6 client MAY request a LoST server domain name in an Options Request Option (ORO), as described in [RFC3315].
如[RFC3315]所述，DHCPv6客户端可能会在选项请求选项（ORO）中请求丢失的服务器域名。
The encoding of the domain name is described in Section 3.
第3节描述了域名的编码。
This option contains a single domain name and, as such, MUST contain precisely one root label.
此选项包含单个域名，因此必须仅包含一个根标签。
This section shows an example of a DHCPv4 option where the DHCP server wants to offer the "example.com" domain name to the client as input to the U-NAPTR LoST discovery procedure. This domain name would be encoded as follows:
本节显示了DHCPv4选项的示例，其中DHCP服务器希望向客户端提供“example.com”域名作为U-NAPTR丢失发现过程的输入。此域名的编码如下：
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|137 |13 | 7 | e | x | a | m | p | l | e | 3 | c | o | m | 0 |
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|137 |13 | 7 | e | x | a | m | p | l | e | 3 | c | o | m | 0 |
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 3: Example for a LoST FQDN DHCPv4 Option
图3：丢失FQDN DHCPv4选项的示例
The following DHCPv4 option code for the Location-to-Service Translation (LoST) Protocol server option has been assigned by IANA:
IANA为位置到服务转换（丢失）协议服务器选项分配了以下DHCPv4选项代码：
Option Name Value Described in
-----------------------------------------------
OPTION_V4_LOST 137 Section 4
Option Name Value Described in
-----------------------------------------------
OPTION_V4_LOST 137 Section 4
IANA has assigned the following DHCPv6 option code for the Location-to-Service Translation (LoST) Protocol option:
IANA已为位置到服务转换（丢失）协议选项分配了以下DHCPv6选项代码：
Option Name Value Described in
------------------------------------------------
OPTION_V6_LOST 51 Section 5
Option Name Value Described in
------------------------------------------------
OPTION_V6_LOST 51 Section 5
If an adversary manages to modify the response from a DHCP server or insert its own response, a LoST client could be led to contact a rogue LoST server under the control of the adversary or be given an invalid address. These threats are documented in [RFC5069]. The security considerations in [RFC2131], [RFC2132], and [RFC3315] are applicable to this document.
如果对手设法修改来自DHCP服务器的响应或插入其自己的响应，则丢失的客户端可能会与对手控制下的恶意丢失服务器联系，或获得无效地址。这些威胁记录在[RFC5069]中。[RFC2131]、[RFC2132]和[RFC3315]中的安全注意事项适用于本文件。
[RFC5222] enumerates the LoST security mechanisms.
[RFC5222]枚举丢失的安全机制。
Andrew Newton reviewed the document and helped simplify the mechanism. Other helpful input was provided by Jari Arkko, Leslie Daigle, Vijay K. Gurbani (Gen-ART Review), David W. Hankins, Russ Housley, Tim Polk, Mark Stapp, and Christian Vogt.
安德鲁·牛顿（Andrew Newton）审阅了该文件，并帮助简化了该机制。贾里·阿尔科、莱斯利·戴格尔、维杰·古巴尼（Gen ART Review）、大卫·W·汉金斯、罗斯·霍斯利、蒂姆·波尔克、马克·斯塔普和克里斯蒂安·沃格特提供了其他有用的意见。
[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", RFC 2119, BCP 14, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 2119，BCP 14，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月。
[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月。
[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月。
[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008.
[RFC5069]Taylor，T.，Tschofenig，H.，Schulzrinne，H.，和M.Shanmugam，“紧急呼叫标记和映射的安全威胁和要求”，RFC 5069，2008年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月。
Authors' Addresses
作者地址
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
美国纽约州纽约市哥伦比亚大学计算机科学系计算机科学大楼450号
EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
James Polk Cisco 2200 East President George Bush Turnpike Richardson, TX 75082 US
James Polk Cisco 2200美国德克萨斯州东总统乔治·布什收费公路理查森75082
EMail: jmpolk@cisco.com
EMail: jmpolk@cisco.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.