[要約] RFC 5859は、DHCPv4でTFTPサーバーアドレスオプションを定義しています。このRFCの目的は、DHCPv4クライアントにTFTPサーバーのアドレスを提供することです。
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と一致するオプションの現在の使用法を文書化します。ワーキンググループは、それらの番号をそれらのオプションに公式に割り当てようとします。このオプションは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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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電話などのVoice Over IP（VoIP）デバイスは、ネットワーク上の構成サーバーから構成をダウンロードする必要があります。DHCPを介してこのサーバーを発見するための2つの一般的に受け入れられている方法があります。DHCPヘッダー[RFC2131]の「スナム」フィールドと「TFTPサーバー名」オプション（66）[RFC2132]。ただし、これらの情報源は両方とも、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構成サーバーの1つ以上の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」フィールドは、1つのIPv4アドレスのみを許可しており、冗長性のために複数のIPアドレスを構成する機能を持つことが望ましいです。（3）一部のDHCPサーバーは、SIADDRとして独自のIPv4アドレスを入力することがわかっています。（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].
この文書のキーワード "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]です。このオプションには、クライアントが使用できる1つ以上の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.
「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.
サーバーアドレスを優先順にリストする必要があり、クライアントはアドレスを順番に使用する必要がありますが、アドレスをランダムに使用するように構成されている場合があります。クライアントは、好きなように提供されるアドレスの数または少数のものを使用する場合があります。たとえば、クライアントが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よりも優先される必要があります。
There is currently no defined IPv6 DHCP equivalent for this option.
現在、このオプションに同等のIPv6DHCPが定義されていることはありません。
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.
Rogue 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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Alexander、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] 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メッセージの認証」、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