Network Working Group R. Johnson
Request for Comments: 5107 J. Jumarasamy
Category: Standards Track K. Kinnear
M. Stapp
Cisco Systems, Inc.
February 2008
DHCP Server Identifier Override Suboption
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
抽象
This memo defines a new suboption of the DHCP relay information option that allows the DHCP relay to specify a new value for the Server Identifier option, which is inserted by the DHCP Server. This allows the DHCP relay to act as the actual DHCP server such that RENEW DHCPREQUESTs will come to the relay instead of going to the server directly. This gives the relay the opportunity to include the Relay Agent option with appropriate suboptions even on DHCP RENEW messages.
このメモは、DHCPリレーは、DHCPサーバによって挿入されたサーバ識別子オプションの新しい値を指定することを可能にするDHCPリレー情報オプションの新しいサブオプションを定義します。これは、DHCPリレーがRENEW DHCPREQUESTsではなく、サーバに直接行くのリレーに来るように、実際のDHCPサーバとして動作させることができます。これは、リレーにメッセージをRENEWでもDHCPに適切なサブオプションでリレーエージェントオプションを含めるする機会を与えてくれます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Server Identifier Override Suboption Definition . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Intellectual Property Rights and Copyright . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 5
There are many situations where a DHCP relay agent is involved, and it can easily insert a Relay Agent Information option [3] with appropriate suboptions into DHCPDISCOVER messages. Once the lease has been granted, however, future DHCPREQUEST messages sent by a client in RENEWING state are sent directly to the DHCP server, as specified in the Server Identifier option. In this case, the relay may not see these DHCPREQUEST messages (depending upon network topology) and thus cannot insert the Relay Agent Information option in the DHCPREQUEST messages.
[3]適切なサブオプションを持つDHCPDISCOVERメッセージにありDHCPリレーエージェントが関与している多くの状況があり、それが簡単にリレーエージェント情報オプションを挿入することができます。リースが許可されていたら、サーバ識別子オプションで指定されている、しかし、状態を更新してクライアントから送信された将来のDHCPREQUESTメッセージは、DHCPサーバーに直接送信されます。この場合、リレーは、これらのDHCPREQUESTメッセージ（ネットワークトポロジに依存して）表示されない場合があり、したがって、DHCPREQUESTメッセージ内のリレーエージェント情報オプションを挿入することはできません。
This DHCP relay agent suboption, Server Identifier Override, allows the relay agent to tell the DHCP server what value to place into the Server Identifier option [5]. Using this, the relay agent can force a host in RENEWING state to send DHCPREQUEST messages to the relay agent instead of directly to the server. The relay agent then has the opportunity to insert the Relay Agent Information option with appropriate suboptions and relay the DHCPREQUEST to the actual server. In this fashion, the DHCP server will be provided with the same relay agent information upon renewals (such as Circuit-ID, Remote-ID, Device Class, etc.) as was provided in the initial DHCPDISCOVER message.
このDHCPリレーエージェントサブオプション、サーバー識別子の上書きは、リレーエージェントはサーバ識別子オプション[5]に配置するどのような値DHCPサーバに伝えることができます。これを使用して、リレーエージェントは、サーバーに直接リレーエージェントにDHCPREQUESTメッセージを送信する代わりにするために状態を更新してホストを強制することができます。リレーエージェントは、適切なサブオプションでリレーエージェント情報オプションを挿入して、実際のサーバにDHCPREQUESTを中継する機会を持っています。このように、DHCPサーバは、初期DHCPDISCOVERメッセージに提供されたように（例えば、回線ID、リモートID、デバイスクラス、など）更新時に同じリレーエージェント情報を提供されます。
In short, this new suboption allows the DHCPv4 relay to function in the same fashion as the DHCPv6 relay [7] currently does.
要するに、この新しいサブオプションは、[7]現在したDHCPv4リレーのDHCPv6リレーと同じ方法で機能することを可能にします。
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 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHOULD"、 "べきではない" "ないもの" "ものとし"、 "推奨"、 "MAY" と "省略可能" にしています[1]で説明されるように解釈されます。
This document uses DHCP terminology as defined in section 1.5 of RFC 2131 [2], with the exception of the term "DHCP relay agent" replacing "BOOTP relay agent".
「BOOTPリレーエージェント」を置き換える用語「DHCPリレーエージェント」を除いて、RFC 2131 [2]のセクション1.5で定義されたように、このドキュメントは、DHCPの用語を使用します。
Other terms used in this document:
この文書で使用される他の用語：
o RENEW DHCPREQUEST - a DHCPREQUEST message sent by a client in RENEWING state
O DHCPREQUESTをRENEW - 状態を更新してクライアントから送信されたDHCPREQUESTメッセージを
The format of the suboption is:
サブオプションの形式は次のとおりです。
Code Len Overriding Server Identifier Address
+-----+-----+-----+-----+-----+-----+
| 11 | n | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+
Figure 1
図1
The option length (n) is 4. The octets "a1" through "a4" specify the value that MUST be inserted into the Server Identifier option by the DHCP Server upon reply.
オプションの長さ（n）が「A4」から「A1」オクテット返信時DHCPサーバによってサーバ識別子オプションに挿入されなければならない値を指定する4です。
DHCP servers that implement this Relay Agent Information suboption MUST use this value, if present in a DHCP message received from a client, as the value to insert into the Server Identifier option in the corresponding response. The DHCP server must also record the address in the suboption for use in subsequent messages to the DHCP client until the next DHCP message is received from the DHCP relay agent.
クライアントから受信したDHCPメッセージ中に存在する場合、このリレーエージェント情報サブオプションを実装するDHCPサーバは対応する応答におけるサーバ識別子オプションに挿入する値として、この値を使用する必要があります。次のDHCPメッセージは、DHCPリレーエージェントから受信されるまで、DHCPサーバもDHCPクライアントへのその後のメッセージで使用するためのサブオプションでアドレスを記録しなければなりません。
If a DHCP server does not understand/implement this Relay Information suboption, it will ignore the suboption, and thus it will insert its own appropriate interface address in the Server Identifier option. In this case, the DHCP Relay will not receive RENEW DHCPREQUEST messages from the client. When configuring a DHCP relay agent to use this suboption, the administrator of the relay agent should take into account whether or not the DHCP server to which the message will be relayed will correctly understand this suboption.
DHCPサーバが/このリレー情報サブオプションを実装して理解していない場合は、サブオプションを無視しますので、それはサーバ識別子オプションで、独自の適切なインターフェイスアドレスを挿入します。この場合、DHCPリレーは、クライアントからRENEW DHCPREQUESTメッセージを受信しません。このサブオプションを使用するようにDHCPリレーエージェントを構成する場合は、リレーエージェントの管理者は、メッセージが中継されるようにDHCPサーバーが正しく、このサブオプションを理解するかどうかを考慮に入れる必要があります。
When servicing a DHCPREQUEST message, the DHCP server would normally look at the Server Identifier option for verification that the address specified there is one of the addresses associated with the DHCP server, silently ignoring the DHCPREQUEST if it does not match a configured DHCP server interface address. If the DHCPREQUEST message contains a Server Identifier Override suboption, however, comparison should be made between the address in this suboption and the Server Identifier option. If both the Server Identifier Override suboption and the Server Identifier option specify the same address, then the server should accept the DHCPREQUEST message for processing, regardless of whether or not the Server Identifier option matches a DHCP server interface.
DHCPREQUESTメッセージにサービスを提供する場合、DHCPサーバは、通常のアドレスは、それが構成されたDHCPサーバのインタフェースアドレスと一致しない場合は静かにDHCPREQUESTを無視して、DHCPサーバに関連付けられたアドレスの一つがある指定されたことの検証のためのサーバ識別子オプションを見てみます。 DHCPREQUESTメッセージは、サーバー識別子の上書きサブオプションが含まれている場合は、しかし、比較がこのサブオプション内のアドレスとサーバ識別子オプションの間でなされるべきです。サーバー識別子の上書きサブオプションとサーバ識別子オプションの両方が同じアドレスを指定すると、サーバーは関係なく、サーバ識別子オプションは、DHCPサーバインターフェイスと一致しているか否かを、処理のためにDHCPREQUESTメッセージを受け入れる必要があります。
The DHCP relay agent should fill in the giaddr field when relaying the message, just as it normally would do.
メッセージを中継する場合に、DHCPリレーエージェントは、それが通常行うのと同じように、giaddrフィールドに記入する必要があります。
In a situation where the DHCP relay agent is configured to forward messages to more than one server, the DHCP relay agent SHOULD forward all DHCP messages to all servers. This applies to RENEW DHCPREQUEST messages as well. The intent is that the DHCP relay agent should not need to maintain state information about the DHCP lease.
DHCPリレーエージェントが複数のサーバーにメッセージを転送するように設定されている状況では、DHCPリレーエージェントは、すべてのサーバーにすべてのDHCPメッセージを転送する必要があります。これは、同様にDHCPREQUESTメッセージを更新するに適用されます。その意図は、DHCPリレーエージェントは、DHCPリースについての状態情報を維持する必要がないということです。
DHCP relay agents implementing this suboption SHOULD also implement and use the DHCPv4 Relay Agent Flags Suboption [4] in order to specify whether the DHCP relay agent received the original message as a broadcast or unicast. The DHCP server receiving a message containing the Server Identifier Override Suboption may use this additional information in processing the message.
このサブオプションを実装するDHCPリレーエージェントはまた、DHCPリレーエージェントは、ブロードキャストまたはユニキャストのように、元のメッセージを受信したかどうかを指定するために、サブオプション[4]のDHCPv4リレーエージェントフラグを実装し、使用すべきです。サーバ識別子オーバーライドサブオプションを含むメッセージを受信したDHCPサーバは、メッセージを処理する際にこの追加情報を使用することができます。
Note that if the DHCP relay agent becomes inaccessible by the DHCP client or loses network access to the DHCP server, further RENEW DHCPREQUEST messages from the DHCP client may not be properly processed and the DHCP client's lease may time out.
DHCPリレーエージェントは、DHCPクライアントがアクセス不能になったか、DHCPサーバーへのネットワークアクセスを失った場合、さらに適切に処理されないことがDHCPクライアントからDHCPREQUESTメッセージを更新し、DHCPクライアントのリースがタイムアウトすることがあります。
Message authentication in DHCP for intradomain use where the out-of-band exchange of a shared secret is feasible is defined in [6]. Potential exposures to attack are discussed in Section 7 of the DHCP protocol specification in [2].
共有秘密のアウトオブバンドの交換が可能であるドメイン内使用のためのDHCPのメッセージ認証は、[6]で定義されています。攻撃に対する潜在的なエクスポージャーは、でDHCPプロトコル仕様のセクション7に記載されている[2]。
The DHCP Relay Agent Information option depends on a trusted relationship between the DHCP relay agent and the DHCP server, as described in Section 5 of RFC 3046. While the introduction of fraudulent DHCP relay agent information options can be prevented by a perimeter defense that blocks these options unless the DHCP relay agent is trusted, a deeper defense using the authentication suboption for DHCP relay agent information option [8] SHOULD be deployed as well.
不正DHCPリレーエージェント情報オプションの導入は、境界防御で防ぐことができますがRFC 3046.のセクション5で説明したようにDHCPリレーエージェント情報オプションは、DHCPリレーエージェントとDHCPサーバ間の信頼関係に依存するブロックこれらのオプションは、DHCPリレーエージェントは、信頼されていない限り、DHCPリレーエージェント情報オプションの認証サブオプションを使用して、より深い防衛は、[8]にも展開する必要があります。
If a rogue DHCP relay agent were inserted between the DHCP client and the DHCP server, it could redirect clients to itself using this suboption. This would allow such a system to later deny RENEW DHCPREQUESTs and thus force clients to discontinue use of their allocated addresses. It could also allow the rogue relay to change, insert, or delete DHCP options in DHCPACK messages and extend leases beyond what the server has allowed. DHCP authentication [6] and/or DHCP Relay Agent Information option authentication [8] would address this case. (Note that, as is always the case, lack of DHCP authentication would allow a rogue DHCP relay agent to change the Server Identifier Override option in the DHCPOFFER and DHCPACK messages without detection. This threat is not new to the Server Identifier Override suboption.)
不正なDHCPリレーエージェントは、DHCPクライアントとDHCPサーバーの間に挿入された場合は、このサブオプションを使用して自分自身にクライアントをリダイレクトすることができます。これは、このようなシステムは、後にDHCPREQUESTsをRENEW否定するので、それらの割り当てられたアドレスの使用を中止するようにクライアントを強制することが可能になります。また、不正なリレーは、変更の挿入、またはDHCPACKメッセージでDHCPオプションを削除し、サーバが許可されたものを超えてリースを延長する可能性があります。 DHCP認証が[6]、および/またはDHCPリレーエージェント情報オプションの認証[8]この場合に対処します。 （常にそうであるように、DHCP認証の欠如が検出されることなくDHCPOFFERとDHCPACKメッセージでサーバー識別子Overrideオプションを変更するには、不正なDHCPリレーエージェントを可能にする、ということに注意してください。この脅威は、サーバー識別子の上書きサブオプションに新しいものではありません。）
This document does not add any new vulnerabilities that were not already present, except in the case where DHCP authentication is already in place, and DHCP clients require its use. It is suggested that DHCP Authentication and DHCP Relay Agent Option Authentication SHOULD be deployed when this option is used, or protection should be provided against the insertion of rogue DHCP relay agents between the client and server.
この文書では、DHCP認証が所定の位置にすでにある場合を除き、既に存在していなかった新たな脆弱性を追加しないと、DHCPクライアントは、その使用を必要としています。このオプションを使用する場合はDHCP認証とDHCPリレーエージェントオプションの認証を展開する必要があり、または保護は、クライアントとサーバ間の不正なDHCPリレーエージェントの挿入に対して提供されるべきであることが示唆されます。
This relay suboption is not intended, by itself, to provide any additional security benefits.
このリレーサブオプションは、任意の追加のセキュリティ上の利点を提供するために、それ自体で、意図していません。
IANA has assigned a suboption number (11) for the Server Identifier Override Suboption from the DHCP Relay Agent Information Option [3] suboption number space.
IANAはDHCPリレーエージェント情報オプション[3]サブオプション番号空間からサーバー識別子の上書きサブオプションのサブオプション番号（11）が割り当てられています。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、要求された権利のオンラインリストを参照してください。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[2] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[3]パトリック、M.、 "DHCPリレーエージェント情報オプション"、RFC 3046、2001年1月。
[4] Kinnear, K., Normoyle, M., and M. Stapp, "The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption", RFC 5010, September 2007.
[4]キニア、K.、Normoyle、M.、およびM.スタップ、 "動的ホスト構成プロトコルバージョン4（DHCPv4の）リレーエージェントのフラグサブオプション"、RFC 5010、2007年9月。
[5] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[5]アレクサンダー、S.とR. Droms、 "DHCPオプションとBOOTPベンダー拡張機能"、RFC 2132、1997年3月。
[6] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[6] Droms、R.とW. Arbaugh、 "DHCPメッセージの認証"、RFC 3118、2001年6月。
[7] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[7] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニーを、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[8] Stapp, M. and T. Lemon, "The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 4030, March 2005.
[8]、RFC 4030「動的ホスト構成プロトコル（DHCP）リレーエージェントオプションの認証サブオプション」スタップ、M.とT.レモン、2005年3月を。
Authors' Addresses
著者のアドレス
Richard A. Johnson Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 US
リチャード・A.ジョンソンシスコシステムズ社170 W.タスマン博士はカリフォルニア州サンノゼ95134米国
Phone: +1 408 526 4000 EMail: raj@cisco.com
電話：+1 408 526 4000 Eメール：raj@cisco.com
Jay Kumarasamy Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 US
ジェイKumarasamyシスコシステムズ社170 W.タスマン博士はカリフォルニア州サンノゼ95134米国
Phone: +1 408 526 4000 EMail: jayk@cisco.com
電話：+1 408 526 4000 Eメール：jayk@cisco.com
Kim Kinnear Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 US
キム・キニアシスコシステムズ社170 W.タスマン博士はカリフォルニア州サンノゼ95134米国
Phone: +1 408 526 4000 EMail: kkinnear@cisco.com
電話：+1 408 526 4000 Eメール：kkinnear@cisco.com
Mark Stapp Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 US
マーク・スタップシスコシステムズ社170 W.タスマン博士はカリフォルニア州サンノゼ95134米国
Phone: +1 408 526 4000 EMail: mjs@cisco.com
電話：+1 408 526 4000 Eメール：mjs@cisco.com
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。