RFC3203 日本語訳
3203 DHCP reconfigure extension. Y. T'Joens, C. Hublet, P. DeSchrijver. December 2001. (Format: TXT=11857 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group Y. T'Joens
Request for Comments: 3203 C. Hublet
Category: Standards Track Alcatel
P. De Schrijver
Mind
December 2001
T'Joensがコメントのために要求するワーキンググループY.をネットワークでつないでください: 3203年のC.Hubletカテゴリ: 標準化過程アルカテルP.De Schrijver心の2001年12月
DHCP reconfigure extension
DHCPは拡大を再構成します。
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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(Dynamic Host Configuration Protocol)と拡大を定義します。 これは、RENEW状態にクライアントを強制するユニキャストFORCERENEWメッセージを紹介することによって、達成されます。 また、設定情報を得るDHCP INFORMメッセージを使用しているホストのためのふるまいは説明されます。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. DHCP force renew
2. DHCP力は更新されます。
This section describes the FORCERENEW message extension.
このセクションはFORCERENEWメッセージ拡張子について説明します。
T'Joens, et al. Standards Track [Page 1] RFC 3203 DHCP reconfigure extension December 2001
T'Joens、他 規格Track[1ページ]RFC3203DHCPは2001年12月に拡大を再構成します。
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 REQUESTに答えるでしょう。 そして、クライアントはイニット状態と放送にDHCP DISCOVERメッセージを支持しに行くでしょう。 サーバは、現在、DHCP OFFERと共に返答することによって、新しいIPアドレスをクライアントに割り当てることができます。 FORCERENEWメッセージが無くなると、DHCPサーバはクライアントからDHCP REQUESTを受けないでしょう、そして、それは指数のbackoffアルゴリズムを使用することで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 INFORM要求でユニキャスト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メッセージの用法が制御事情で使用されるべきであることにさらに注意してください。
T'Joens, et al. Standards Track [Page 2] RFC 3203 DHCP reconfigure extension December 2001
T'Joens、他 規格Track[2ページ]RFC3203DHCPは2001年12月に拡大を再構成します。
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.
ホームゲートウェイの自動構成、(より一般的である、Network Termination設備) 公共のネットワークにおいて、DHCPによって目的を達成できます、[DSL_autoconf]で説明されるように。 サービス変化か停電を許容するために、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サーバは例えばグローバルに発送されたIPアドレスを得て、新しいDHCP初期化セッションのために尋ねるクライアントの引き金となることができます。
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.
しっかり制御された条件のもとでは、全体のサブネットの番号を付け替える1クライアントあたりのクライアントに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クライアント実装に加えられるのが新しい州を必要としません。 これは、変えるためにコードの量を最小にします。 また、それは、サーバによってリースRENEWALがネットワーク用法かDHCPサーバ荷重を最適化するように動かされるのを許容します。(サーバを使用できます)。
T'Joens, et al. Standards Track [Page 3] RFC 3203 DHCP reconfigure extension December 2001
T'Joens、他 規格Track[3ページ]RFC3203DHCPは2001年12月に拡大を再構成します。
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 | | |
+----------------------------------------+
+--------+ +------+ | イニット/| +-->+イニット+<。---------------+-------------------+ | リブート| | +--+---+ | | +---+----+ //がDHCPDISCOVERを送るDHCPNAK| | | 再開| (放送) | | | | vに対して-------------+ | | -/はDHCPREQUESTを送ります。| +----+------+ DHCPOFFER/DHCPDECLINE| | (放送)| | 選択|----------+ | | v| +----+------+ | | +---+----+ | DHCPOFFER/DHCPREQUEST| | | リブート+---------+ (放送)| | +---+----+ v| | | +----+-------+ DHCPNAK/停止ネットワーク| + 要求| | 満期のDHCPACK/+を賃貸してください。----+-------+ | | リースを記録してください。| | | セットタイマDHCPACK/記録リース| | | Set T1&T2に対して| | | +--+----+ DHCPFORCE+---+---+ +----+---+ +----------------->+バウンド+---------->+は+を更新します。---------+が縛り直す>。| +--++--+ T1は+++を吐き出します。---+ T2は+を吐き出します。----+---+ ^ /DHCPREQUEST | | /放送| 賃貸借契約へのDHCPACK| | DHCPREQUEST| | サーバ| | | +----------------------------------------+
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メッセージタイプ)は新しい値で広げられます: DHCPFORCERENEW(9)
5. IANA Considerations
5. IANA問題
The new value for DHCP option 53 (DHCP message type) to indicate a DHCPFORCERENEW message is 9.
DHCPオプション53(DHCPメッセージタイプ)がDHCPFORCERENEWメッセージを示す新しい値は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メッセージはクライアントによって静かに捨てられるべきです。
T'Joens, et al. Standards Track [Page 4] RFC 3203 DHCP reconfigure extension December 2001
T'Joens、他 規格Track[4ページ]RFC3203DHCPは2001年12月に拡大を再構成します。
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.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[DHCP-AUTH] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[DHCP-AUTH] DromsとR.とW.Arbaugh、「DHCPメッセージのための認証」、RFC3118、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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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アルカテルネットワーク戦略グループフランシスWellesplein1、アントワープ(ベルギー)が電話をする2018: +32 3 240 7890はメールされます: yves.tjoens@alcatel.be
Peter De Schrijver Mind NV Vaartkom 11 3000 Leuven EMail: p2@mind.be
ピーターDe SchrijverはネバダVaartkom11 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、Kontich、ベルギーが電話をする2550: +32 3 450 3322はメールされます: Christian.Hublet@alcatel.be
T'Joens, et al. Standards Track [Page 5] RFC 3203 DHCP reconfigure extension December 2001
T'Joens、他 規格Track[5ページ]RFC3203DHCPは2001年12月に拡大を再構成します。
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
T'Joens, et al. Standards Track [Page 6]
T'Joens、他 標準化過程[6ページ]
一覧
スポンサーリンク
