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
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サーバのアドレス」オプションにこのメモ文書の既存の使用。現在使用されているオプションの数は、このメモは範囲128から223までのオプション番号のいずれかの既存の用途は文書化されなければならないことを宣言RFC 3942との契約におけるオプションの現在の使用状況、および動的ホスト構成を文書150です。ワーキンググループは、正式にそれらのオプションにそれらの番号を割り当てしようとします。オプションは、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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さ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
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ボイスオーバーIP電話など（VoIP）のデバイスは、ネットワーク上のコンフィギュレーション・サーバから設定をダウンロードする必要があります。 DHCP経由でこのサーバを発見するには、2つの一般的に受け入れられている方法があります。 DHCPヘッダ[RFC2131]および "TFTPサーバ名" オプション（66）[RFC2132]に "SNAME" フィールド。これらの情報源の両方が、しかし、TFTPサーバのホスト名が含まれています。そのホスト名は、IPアドレスに変換する必要があります。これを実現するための通常の方法は、DNS [RFC1034]になります。これは、この変換を実行するために、DNSプロトコルを実装する必要があります（おそらく限られたフラッシュ、メモリ、および/または処理リソースを持つ）のVoIPデバイス内のファームウェアを意味します。これは、デバイスが起動し、そのコールエージェントと通信するために、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デバイスによって情報が直接使用すること、VoIPの構成サーバー（複数可）の代わりに、ホスト名の1つまたは複数のIPアドレスを渡すことができます。
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」フィールドは、1つのIPv4アドレスが可能になり、冗長性のために複数のIPアドレスを設定する機能を有することが望ましいです。 （3）一部のDHCPサーバはSIADDRとして、自分のIPv4アドレスを記入することが見出されています。 （4）一部の顧客は、既に他の目的のための「SIADDR」フィールドを使用していました。そして最後に（5）コンフィギュレーションサーバは不適切「TFTPサーバ名」オプション（66）を利用して、コンフィギュレーションファイルを提供するTFTP以外のプロトコルを使用することができます。
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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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 | ...
+-----+-----+-----+-----+-----+-----+
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.
「レン」フィールドは、4つのオクテット（4、8、12、等）の整数倍の長さを指定しなければなりません。これが当てはまらない場合オプションが受信された場合、オプション情報は無視しなければなりませんが、さらにオプション処理を継続してもよいです。 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.
サーバアドレスは、優先順にリストする必要があり、クライアントは順次アドレスを使用するべきであるが、ランダムにアドレスを使用するように構成されてもよいです。クライアントは、できるだけ多くまたはそれが好きとして提供アドレスのように、いくつかを使用することができます。例えば、クライアントは、2つの構成サーバのアドレスを受け入れることができるだけである場合、それは第2のアドレスの後に提供される任意の他のアドレスを無視することができます。
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秒の待機時間で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を超える優先順位を持つべきである（SHOULD）。
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].
共有秘密のアウトオブバンド交換が可能であるドメイン内の使用のためのDHCPのメッセージ認証は[RFC3118]で定義されています。攻撃に対する潜在的なエクスポージャーは、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]アレクサンダー、S.とR. Droms、 "DHCPオプションとBOOTPベンダー拡張機能"、RFC 2132、1997年3月。
[RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options", RFC 3942, November 2004.
[RFC3942]フォルツ、B.、RFC 3942 "動的ホスト構成プロトコルバージョン4（DHCPv4の）オプションを再分類"、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メッセージの認証"、RFC 3118、2001年6月。
Author's Address
著者のアドレス
Richard A. Johnson Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA
リチャード・A.ジョンソンシスコシステムズ社170 W.タスマン博士はカリフォルニア州サンノゼ95134 USA
Phone: +1 408 526 4000 EMail: raj@cisco.com
電話：+1 408 526 4000 Eメール：raj@cisco.com