[要約] RFC 3203は、DHCP再構成拡張に関する仕様であり、DHCPクライアントが再構成を要求するための新しいメッセージタイプを定義しています。目的は、ネットワークの変更や障害時に効率的な再構成を可能にすることです。

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

DHCP再構成拡張機能

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.

Copyright(c)The Internet Society(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(動的ホスト構成プロトコル)への拡張機能を定義して、DHCPサーバー(たとえば、新しいIPアドレスおよび/またはローカル構成パラメーターなど)によってトリガーされる単一のホストの動的な再構成を可能にします。これは、クライアントに更新状態を強制するユニキャスト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].

キーワード「必須」、「そうしない」、「必須」、「必要」、「しなければ」、「そうしない」、「はそうではない」、「そうでない」、「推奨」、「5月」、「オプション」は、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メッセージを送信します。Unicast Forcerenewメッセージを受信すると、クライアントは状態を更新状態に変更し、通常のDHCP手順に従ってリースを更新しようとします。サーバーがクライアントに新しいIPアドレスを割り当てたい場合、DHCP NAKを使用してDHCPリクエストに返信します。その後、クライアントはINIT状態に戻り、DHCP発見メッセージをブロードキャストします。サーバーは、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情報リクエストを使用して他のローカル構成パラメーターを取得した可能性があります。このようなクライアントは、ローカル構成パラメーターの潜在的な新しいセットを取得するために、新しい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.

さらに、クライアントアドレスまたはローカル構成パラメーターを再構成するためのforcerNewメッセージの使用は、アクティブセッションの中断につながる可能性があること、およびこれらの手順は制御された状況で使用されるべきであることに注意してください。

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アドレスを配ることができます。グローバルインターネットサービスやエンタープライズ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メッセージレイアウトを使用します。DHCPオプション53(DHCPメッセージタイプ)は新しい値で拡張されています:DHCP forcerenew(9)

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を使用してトラフィックをスヌープおよびスプーフィングするために、[dhcp-auth]で説明されている手順を使用して、forcerenewメッセージを認証する必要があります。認証に失敗した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メッセージでクライアントにあふれることによるサービス拒否攻撃に対して脆弱です。偽のForcerenewメッセージの認証に伴う計算は、クライアントが実行されているデバイスを圧倒する可能性があります。

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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.

著者は、これらの手順への建設的なコメントについて、NortelのDavid Allanに感謝したいと思います。

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

Yves T'Joens Alcatel Network Strategy Group Francis Wellesplein 1、2018 Antwerp、Belgium電話:32 3 240 7890メール:yves.tjoens@alcatel.be

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

Peter de Schrijver Mind 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

Alcatel Broadband Networking Division Veldkant 33b、2550 Kontich、Belgium電話:32 3 450 3322メール:churisty.hublet@alcatel.be

10. 完全な著作権声明

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

Copyright(c)The Internet Society(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エディター機能の資金は現在、インターネット協会によって提供されています。