Internet Engineering Task Force (IETF) R. Johnson
Request for Comments: 5859 Cisco Systems, Inc.
Category: Informational June 2010
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Johnson
Request for Comments: 5859 Cisco Systems, Inc.
Category: Informational June 2010
ISSN: 2070-1721
TFTP Server Address Option for DHCPv4
DHCPv4的TFTP服务器地址选项
Abstract
摘要
This memo documents existing usage for the "TFTP Server Address" option. The option number currently in use is 150. This memo documents the current usage of the option in agreement with RFC 3942, which declares that any pre-existing usages of option numbers in the range 128-223 should be documented, and the Dynamic Host Configuration working group will try to officially assign those numbers to those options. The option is defined for DHCPv4 and works only with IPv4 addresses.
此备忘录记录了“TFTP服务器地址”选项的现有用法。当前使用的选项号为150。本备忘录记录了与RFC 3942一致的选项的当前使用情况，RFC 3942声明应记录128-223范围内选项编号的任何预先存在的使用情况，动态主机配置工作组将尝试将这些编号正式分配给这些选项。该选项是为DHCPv4定义的，仅适用于IPv4地址。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5859.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5859.
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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. TFTP Server Address Option Definition . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. TFTP Server Address Option Definition . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . . 6
Voice over IP (VoIP) devices, such as IP phones, have a need to download their configuration from a configuration server on the network. There are two commonly accepted methods to discover this server via DHCP; the "sname" field in the DHCP header [RFC2131] and the "TFTP Server Name" option (66) [RFC2132]. Both of these sources of information, however, contain the TFTP server's hostname. That hostname must then be translated to an IP address. The usual method to accomplish this would be DNS [RFC1034]. This means the firmware in a VoIP device (with possibly limited flash, memory, and/or processing resources) would need to implement the DNS protocol in order to perform this translation. This would also introduce an additional unnecessary point of failure whereby the device is dependent on the DNS server infrastructure in order to boot up and communicate with its call agent.
IP语音（VoIP）设备（如IP电话）需要从网络上的配置服务器下载其配置。有两种常用的方法可以通过DHCP发现此服务器；DHCP头[RFC2131]中的“sname”字段和“TFTP服务器名称”选项（66）[RFC2132]。但是，这两个信息源都包含TFTP服务器的主机名。然后必须将该主机名转换为IP地址。通常的方法是DNS[RFC1034]。这意味着VoIP设备中的固件（可能具有有限的闪存、内存和/或处理资源）需要实现DNS协议才能执行此转换。这还将引入一个额外的不必要的故障点，设备依赖于DNS服务器基础设施，以便启动并与其呼叫代理通信。
In order to eliminate DNS as a point of failure and to keep the firmware in such a VoIP device to a minimum, the "VoIP Configuration Server Address" option (150) was introduced. This option allows the DHCP server to pass one or more IP addresses of the VoIP configuration server(s) instead of the hostname, thus making the information directly usable by the VoIP device.
为了消除DNS作为故障点，并将此类VoIP设备中的固件保持在最低限度，引入了“VoIP配置服务器地址”选项（150）。此选项允许DHCP服务器传递VoIP配置服务器的一个或多个IP地址，而不是主机名，从而使VoIP设备可以直接使用信息。
Other reasons for this option are (1) the "siaddr" field is not configurable on some DHCP servers; (2) the "siaddr" field only allows for one IPv4 address, and it is desirable to have the ability to configure multiple IP addresses for redundancy; (3) some DHCP servers have been found to fill in their own IPv4 address as siaddr; (4) some customers were already using the "siaddr" field for other purposes; and finally (5) the configuration server may use a protocol other than TFTP to serve configuration files, making the use of the "TFTP Server Name" option (66) inappropriate.
此选项的其他原因是（1）“siaddr”字段在某些DHCP服务器上不可配置；（2） “siaddr”字段只允许一个IPv4地址，最好能够配置多个IP地址以实现冗余；（3） 一些DHCP服务器被发现将自己的IPv4地址填写为siaddr；（4） 一些客户已经将“siaddr”字段用于其他目的；最后（5）配置服务器可以使用除TFTP之外的协议来服务配置文件，使得使用“TFTP服务器名称”选项（66）不合适。
In cases where other download server address information also appears in the response packet, such as "sname" and "TFTP Server Name", it is left to the device to decide which piece of information to use.
如果其他下载服务器地址信息也出现在响应包中，例如“sname”和“TFTP服务器名称”，则由设备决定使用哪一条信息。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The TFTP Server Address option is a DHCP option [RFC2132]. The option contains one or more IPv4 addresses that the client MAY use. The current use of this option is for downloading configuration from a VoIP server via TFTP; however, the option may be used for purposes other than contacting a VoIP configuration server.
TFTP服务器地址选项是DHCP选项[RFC2132]。该选项包含客户端可能使用的一个或多个IPv4地址。此选项当前用于通过TFTP从VoIP服务器下载配置；但是，该选项可用于联系VoIP配置服务器以外的其他目的。
The format of the option is:
该选项的格式为：
Code Len IPv4 Configuration Server Address(es)
+-----+-----+-----+-----+-----+-----+
| 150 | n | IPv4 address | ...
+-----+-----+-----+-----+-----+-----+
Code Len IPv4 Configuration Server Address(es)
+-----+-----+-----+-----+-----+-----+
| 150 | n | IPv4 address | ...
+-----+-----+-----+-----+-----+-----+
Figure 1
图1
The option minimum length (n) is 4.
选项最小长度（n）为4。
The "Len" field must specify a length that is an integral multiple of 4 octets (4, 8, 12, etc.). If an option is received where this is not the case, the option information MUST be ignored, but further option processing may continue. Dividing this "Len" value by 4 will give the number of IPv4 VoIP configuration server addresses that are specified in the option.
“Len”字段必须指定长度为4个八位字节（4、8、12等）的整数倍。如果收到的选项不是这种情况，则必须忽略选项信息，但进一步的选项处理可能会继续。将此“Len”值除以4将给出选项中指定的IPv4 VoIP配置服务器地址数。
The option MUST NOT be specified by the DHCP client, as it is intended only to be returned from the DHCP server. If the DHCP client wants to receive this information from the server, it needs to include the number 150 in the "DHCP Parameter List" option (55).
该选项不能由DHCP客户端指定，因为它只打算从DHCP服务器返回。如果DHCP客户端希望从服务器接收此信息，则需要在“DHCP参数列表”选项（55）中包含数字150。
Server addresses SHOULD be listed in order of preference, and the client SHOULD use the addresses sequentially but may be configured to use addresses randomly. The client may use as many or as few of the addresses provided as it likes. For example, if the client is only capable of accepting two configuration server addresses, it may ignore any other addresses provided after the second address.
服务器地址应按优先顺序列出，客户端应按顺序使用地址，但可以配置为随机使用地址。客户可以使用任意数量的地址。例如，如果客户端只能接受两个配置服务器地址，它可能会忽略第二个地址之后提供的任何其他地址。
Each TFTP server address that is being used by the client should be tried a total of four times with a 4-second wait time before proceeding to the next address.
客户机正在使用的每个TFTP服务器地址在转到下一个地址之前，应总共尝试四次，等待时间为4秒。
When this option appears along with the TFTP Server Name option (66) [RFC2132], this option SHOULD have priority over option 66.
当此选项与TFTP服务器名称选项（66）[RFC2132]一起出现时，此选项应优先于选项66。
There is currently no defined IPv6 DHCP equivalent for this option.
当前没有为此选项定义IPv6 DHCP等效项。
A rogue DHCP server could use this option in order to coerce a client into downloading configuration data from an alternate configuration server, and thus gain control of the device's configuration. This, however, is no more of a security threat than similar attacks using other DHCP options that specify server names or addresses, of which there are many. If this is a concern, then DHCP authentication may be used, but even secure delivery of an address over DHCP does not protect the subsequent insecure download over TFTP. TFTP itself provides no authentication or access control mechanisms, so even if DHCP messages were authenticated, downloading the configuration would still be insecure, unless some object-level security mechanisms were used.
恶意DHCP服务器可以使用此选项强制客户端从备用配置服务器下载配置数据，从而获得对设备配置的控制。然而，这与使用其他DHCP选项（其中有许多指定服务器名称或地址）的类似攻击相比，并不构成安全威胁。如果这是一个问题，那么可以使用DHCP身份验证，但是即使通过DHCP安全地传递地址也不能保护随后通过TFTP进行的不安全下载。TFTP本身不提供身份验证或访问控制机制，因此即使DHCP消息经过身份验证，下载配置仍然是不安全的，除非使用了某些对象级安全机制。
Where security concerns are an issue, it is suggested that configuration files should be signed by a trusted agent. Configuration files may also be encrypted based on a configuration parameter on the DHCP client device. In other words, there are various methods to ensure the integrity of configuration data independent from ensuring the integrity of this DHCP option or even DHCP itself. The full extent of such options is far too broad to be addressed in this document.
如果存在安全问题，建议由受信任的代理对配置文件进行签名。配置文件也可以基于DHCP客户端设备上的配置参数进行加密。换句话说，有各种方法可以确保配置数据的完整性，而不必确保此DHCP选项甚至DHCP本身的完整性。这些选择的范围太广，本文件无法处理。
Message authentication in DHCP for intradomain use where the out-of-band exchange of a shared secret is feasible is defined in [RFC3118]. Potential exposures to attack are discussed in Section 7 of the DHCP protocol specification [RFC2131].
[RFC3118]中定义了DHCP中用于域内使用的消息身份验证，其中共享秘密的带外交换是可行的。DHCP协议规范[RFC2131]第7节讨论了潜在的攻击风险。
IANA has assigned DHCP option number 150, in accordance with [RFC3942].
IANA已根据[RFC3942]分配DHCP选项编号150。
[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月。
[RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options", RFC 3942, November 2004.
[RFC3942]Volz，B.“重新分类动态主机配置协议版本4（DHCPv4）选项”，RFC 3942，2004年11月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118]Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
Author's Address
作者地址
Richard A. Johnson Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA
Richard A.Johnson思科系统公司170 W.Tasman Dr.San Jose，CA 95134美国
Phone: +1 408 526 4000
EMail: raj@cisco.com
Phone: +1 408 526 4000
EMail: raj@cisco.com