Network Working Group                                         Y. T'Joens
Request for Comments: 3203                                     C. Hublet
Category: Standards Track                                        Alcatel
                                                         P. De Schrijver
                                                                    Mind
                                                           December 2001
        
                       DHCP reconfigure extension
        

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)の最新版を参照してください。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2001). All Rights Reserved.

著作権(C)インターネット協会(2001)。全著作権所有。

Abstract

抽象

This document defines extensions to DHCP (Dynamic Host Configuration Protocol) to allow dynamic reconfiguration of a single host triggered by the DHCP server (e.g., a new IP address and/or local configuration parameters). This is achieved by introducing a unicast FORCERENEW message which forces the client to the RENEW state. The behaviour for hosts using the DHCP INFORM message to obtain configuration information is also described.

この文書では、DHCPサーバ(例えば、新しいIPアドレスおよび/またはローカル設定パラメータ)によってトリガ単一のホストの動的な再構成を可能にするために、DHCP(動的ホスト構成プロトコル)の拡張機能を定義します。これはRENEW状態にクライアントを強制的にユニキャストFORCERENEWメッセージを導入することによって達成されます。 DHCPを使用するホストのための動作設定情報を取得するためにメッセージを通知も記載されています。

1. Introduction
1. はじめに

The procedures as described within this document allow the dynamic reconfiguration of individual hosts.

この文書内で説明したような手順は、個々のホストの動的な再構成を可能にします。

1.1 Conventions
1.1表記

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"、 "SHOULD"、 "べきではない" "ないもの" "ものとし"、 "推奨"、 "MAY" と "省略可能" にしていますRFC 2119 [RFC2119]に記載されているように解釈されます。

2. DHCP force renew
2. DHCP力更新

This section describes the FORCERENEW message extension.

このセクションでは、FORCERENEWメッセージ拡張について説明します。

2.1 Terminology
2.1用語

DHCP client : host to be reconfigured using DHCP.

DHCPクライアント:ホストがDHCPを使用して再構成します。

DHCP server : server which configured the DHCP client.

DHCPサーバ:DHCPクライアントを構成したサーバー。

2.2 Force renew procedures
2.2強制手続を更新

The DHCP server sends a unicast FORCERENEW message to the client. Upon receipt of the unicast FORCERENEW message, the client will change its state to the RENEW state, and will then try to renew its lease according to normal DHCP procedures. If the server wants to assign a new IP address to the client, it will reply to the DHCP REQUEST with a DHCP NAK. The client will then go back to the init state and broadcast a DHCP DISCOVER message. The server can now assign a new IP address to the client by replying with a DHCP OFFER. If the FORCERENEW message is lost, the DHCP server will not receive a DHCP REQUEST from the client and it should retransmit the FORCERENEW message using an exponential backoff algorithm. Depending on the bandwidth of the network between server and client, the server should choose a delay. This delay grows exponentially as retransmissions fail. The amount of retransmissions should be limited.

DHCPサーバは、クライアントへのユニキャストFORCERENEWメッセージを送信します。ユニキャストFORCERENEWメッセージを受信すると、クライアントがRENEW状態にその状態を変更し、その後通常のDHCP手順に従ってリースを更新しようとします。サーバーがクライアントに新しいIPアドレスを割り当てたい場合は、DHCP NAKとDHCP要求に応答します。次に、クライアントはバックのinit状態に戻り、DHCP DISCOVERメッセージをブロードキャストします。サーバーがDHCPオファーを返信することで、クライアントに新しいIPアドレスを割り当てることができます。 FORCERENEWメッセージが失われた場合、DHCPサーバは、クライアントからのDHCP要求を受信しません、それは指数バックオフアルゴリズムを使用してFORCERENEWメッセージを再送する必要があります。サーバとクライアント間のネットワークの帯域幅に応じて、サーバーは、遅延を選択する必要があります。再送信が失敗すると、この遅延は指数関数的に増加します。再送の量を制限する必要があります。

The procedures described above assume the server to send a unicast FORCERENEW message to the client. Receipt of a multicast FORCERENEW message by the client should be silently discarded.

上記の手順は、クライアントへのユニキャストFORCERENEWメッセージを送信するサーバを想定します。クライアントによるマルチキャストFORCERENEWメッセージの受信は静かに捨てられるべきです。

It can be that a client has obtained a network address through some other means (e.g., manual configuration) and has used a DHCP INFORM request to obtain other local configuration parameters. Such clients should respond to the receipt of a unicast FORCERENEW message with a new DHCP INFORM request so as to obtain a potential new set of local configuration parameters. Note that the usage of these procedures are limited to the set of options that are eligible for configuration by DHCP and should not override manually configured parameters.

これは、クライアントが他の手段(例えば、手動設定)を介してネットワークアドレスを取得しており、他のローカル構成パラメータを取得するための要求を通知DHCPを使用したこととすることができます。このようなクライアントは、ローカル設定パラメータの潜在的な新しいセットを取得するように要求をINFORM新しいDHCPにユニキャストFORCERENEWメッセージの受信に応答する必要があります。これらの手順の使用がDHCPによって設定の対象となり、手動で設定されたパラメータを上書きすべきではありませんオプションのセットに限定されていることに注意してください。

Note further that usage of the FORCERENEW message to reconfigure a client address or local configuration parameters can lead to the interruption of active sessions, and that as such these procedures should be used in controlled circumstances.

さらに、クライアントのアドレスを再設定したり、ローカルの設定パラメータは、アクティブなセッションの中断につながり、そしてそのようなこれらの手順は、制御された環境で使用されるべきであることができるFORCERENEWメッセージの使用を注意してください。

2.3 Example usage
2.3使用例
2.3.1 Embedded DHCP clients
2.3.1組み込みDHCPクライアント

The autoconfiguration of home gateways (more generically Network Termination equipment) for public networking purposes can be achieved through means of DHCP, as described in [DSL_autoconf]. In order to allow service changes or service interruption, the FORCERENEW message can trigger the home gateway to contact the DHCP server, prior to the expiry of the lease.

[DSL_autoconf]で説明したように、公共ネットワークの目的のためにホームゲートウェイ(より一般的にネットワーク終端機器)の自動設定は、DHCPの手段によって達成することができます。サービスの変更またはサービスの中断を可能にするために、FORCERENEWメッセージは、以前のリースの満了に、DHCPサーバに連絡するホームゲートウェイをトリガすることができます。

2.3.2 Hospitality service scenario
2.3.2ホスピタリティサービスシナリオ

In self provisioned networks, e.g., hotel rooms, the hotel owned DHCP server can hand out limited use IP addresses, that allows the customer to consume local services or select external services from a web browser interface. In order to allow external services through other service providers, e.g., global internet services or enterprise VPN services, the DHCP server can trigger the client to ask for a new DHCP initialization session so as to obtain e.g., a globally routed IP address.

セルフプロビジョニングネットワークでは、例えば、ホテルの部屋、ホテル所有のDHCPサーバは、限定使用のIPアドレスを配ることができ、それは、顧客がローカルサービスを消費するか、Webブラウザインタフェースから外部サービスを選択することができます。例えば、グローバルなインターネットサービスや企業向けVPNサービス、他のサービスプロバイダを介して外部のサービスを可能にするために、DHCPサーバは、例えば得られるように、新しいDHCPの初期化セッションに対してグローバルにルーティングされたIPアドレスを依頼するクライアントをトリガすることができます。

2.3.3 Network renumbering
2.3.3ネットワークリナンバリング

Under tightly controlled conditions, the FORCERENEW procedures can be used to brute force the renumbering of entire subnets, client per client, under control of a DHCP server.

厳密に制御された条件下で、FORCERENEW手順は、DHCPサーバの制御下で、サブネット全体のリナンバリング、クライアントごとにクライアントをブルートフォースするために使用することができます。

2.4 Rationale
2.4理論的根拠

The approach as described in this document has a number of advantages. It does not require new states to be added to the DHCP client implementation. This minimizes the amount of code to be changed. It also allows lease RENEWAL to be driven by the server, which can be used to optimize network usage or DHCP server load.

この文書に記載されているようなアプローチは多くの利点を有しています。これは、DHCPクライアントの実装に追加する新しい状態を必要としません。これは、コードの量を変更することが最小限に抑えます。それはまた、リース更新は、ネットワークの使用又はDHCPサーバの負荷を最適化するために使用することができるサーバによって駆動されることを可能にします。

3. Extended DHCP state diagram
3.拡張DHCP状態図
+--------+             +------+
| Init / |         +-->+ Init +<---------------+-------------------+
| Reboot |         |   +--+---+                |                   |
+---+----+     DHCPNAK/ -/Send DHCPDISCOVER    |                   |
    |          Restart    |     (broadcast)    |                   |
    |              |      v   v-------------+  |                   |
 -/Send DHCPREQUEST| +----+------+    DHCPOFFER/DHCPDECLINE        |
    |   (broadcast)| | Selecting |----------+  |                   |
    v              | +----+------+             |                   |
+---+----+         |   DHCPOFFER/DHCPREQUEST   |                   |
| Reboot +---------+  (broadcast)              |                   |
+---+----+                v                    |                   |
    |                +----+-------+            DHCPNAK /halt network
    |                + Requesting |            |       lease expired
   DHCPACK/          +----+-------+            |                   |
   Record lease           |                    |                   |
   set timers         DHCPACK/Record lease     |                   |
    |                     v   Set T1 & T2      |                   |
    |                  +--+----+DHCPFORCE  +---+---+          +----+---+
    +----------------->+ Bound +---------->+ Renew +--------->+ Rebind |
                       +--+-+--+T1 expires +-+-+---+T2 expires+----+---+
                          ^     /DHCPREQUEST | |    /broadcast     |
                       DHCPACK    to leasing | |    DHCPREQUEST    |
                          |        server    | |                   |
                          +----------------------------------------+
        
4. Message layout
4.メッセージのレイアウト

The FORCERENEW message makes use of the normal DHCP message layout with the introduction of a new DHCP message type. DHCP option 53 (DHCP message type) is extended with a new value: DHCPFORCERENEW (9)

FORCERENEWメッセージは、新しいDHCPメッセージタイプの導入により、通常のDHCPメッセージのレイアウトを使用しています。 DHCPFORCERENEW(9):DHCPオプション53(DHCPメッセージタイプ)が新しい値で拡張されています

5. IANA Considerations
5. IANAの考慮事項

The new value for DHCP option 53 (DHCP message type) to indicate a DHCPFORCERENEW message is 9.

DHCPFORCERENEWメッセージを示すためにDHCPオプション53(DHCPメッセージタイプ)の新しい値は9です。

6. Security Considerations
6.セキュリティの考慮事項

As in some network environments FORCERENEW can be used to snoop and spoof traffic, the FORCERENEW message MUST be authenticated using the procedures as described in [DHCP-AUTH]. FORCERENEW messages failing the authentication should be silently discarded by the client.

FORCERENEWはスヌープと偽装トラフィックに使用することができるいくつかのネットワーク環境のように、FORCERENEWメッセージは、[DHCP-AUTH]に記載の手順を使用して認証されなければなりません。認証に失敗FORCERENEWメッセージは静かに、クライアントによって破棄されなければなりません。

6.1 Protocol vulnerabilities
6.1プロトコルの脆弱性

The mechanism described in this document is vulnerable to a denial of service attack through flooding a client with bogus FORCERENEW messages. The calculations involved in authenticating the bogus FORECERENEW messages may overwhelm the device on which the client is running.

この文書で説明するメカニズムは、偽のFORCERENEWメッセージをクライアントに氾濫によるサービス拒否攻撃に対して脆弱です。偽のFORECERENEWメッセージを認証に関わる計算は、クライアントが実行されているデバイスを圧倒することがあります。

7. References
7.参考

[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.

[DHCP] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。

[DHCP-AUTH] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.

[DHCP-AUTH] Droms、R.とW. Arbaugh、 "DHCPメッセージの認証"、RFC 3118、2001年6月。

[DSL_autoconf] Technical Report TR-044, "Auto-Configuration for Basic Internet (IP-based) Services", DSL Forum, November 2001

[DSL_autoconf]テクニカルレポートTR-044、 "基本的なインターネットのための自動設定(IPベース)サービス"、DSLフォーラム、2001年11月

[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月。

8. Acknowledgements
8.謝辞

The authors would like to thank David Allan, Nortel, for the constructive comments to these procedures.

著者は、これらの手順への建設的なコメントのために、デビッド・アラン、ノーテルに感謝したいと思います。

9. Authors' Addresses
9.著者のアドレス

Yves T'joens Alcatel Network Strategy Group Francis Wellesplein 1, 2018 Antwerp, Belgium Phone: +32 3 240 7890 EMail: yves.tjoens@alcatel.be

イヴT'joensアルカテル・ネットワーク戦略グループフランシスWellesplein 1、2018年アントワープ、ベルギー電話:+32 3 240 7890 Eメール:yves.tjoens@alcatel.be

Peter De Schrijver Mind NV Vaartkom 11 3000 Leuven EMail: p2@mind.be

ピーター・デ・SchrijverマインドNV Vaartkom 11 3000ルーベンメール:p2@mind.be

Alcatel Broadband Networking Division Veldkant 33b, 2550 Kontich, Belgium Phone: +32 3 450 3322 EMail: Christian.Hublet@alcatel.be

アルカテル・ブロードバンドネットワーク部門Veldkant 33bと、2550 Kontich、ベルギー電話:+32 3 450 3322 Eメール:Christian.Hublet@alcatel.be

10. Full Copyright Statement
10.完全な著作権声明

Copyright (C) The Internet Society (2001). All Rights Reserved.

著作権(C)インターネット協会(2001)。全著作権所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。