RFC3942 日本語訳
3942 Reclassifying Dynamic Host Configuration Protocol version 4(DHCPv4) Options. B. Volz. November 2004. (Format: TXT=13996 bytes) (Updates RFC2132) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Volz Request for Comments: 3942 Cisco Systems, Inc. Updates: 2132 November 2004 Category: Standards Track
コメントを求めるワーキンググループB.フォルツ要求をネットワークでつないでください: 3942のシスコシステムズInc.アップデート: 2132 2004年11月のカテゴリ: 標準化過程
Reclassifying Dynamic Host Configuration Protocol
version 4 (DHCPv4) Options
Dynamic Host Configuration Protocolバージョン4(DHCPv4)オプションに分類し直します。
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 (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document updates RFC 2132 to reclassify Dynamic Host Configuration Protocol version 4 (DHCPv4) option codes 128 to 223 (decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939. This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options.
このドキュメントは、RFC2939によると、IANAによって管理されるように公的に定義されたオプションとして128〜223(10進)にDynamic Host Configuration Protocolバージョン4(DHCPv4)オプションコードに分類し直すためにRFC2132をアップデートします。 このドキュメントは、これらのオプションコードを今後のオプションのための公的に定義されたDHCPオプションとして課題に利用可能にするようIANAに指示します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.1. Publicly Defined Options Range . . . . . . . . . . . . . 2
3.2. Site-Specific Options Range . . . . . . . . . . . . . . 3
4. Reclassifying Options . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 7
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 要件記法. . . . . . . . . . . . . . . . . . . . 2 3 バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . . . . 2 3.1。 公的に定義されたオプションは.23.2に及びます。 サイト特有のオプションは.3 4に及びます。 オプション. . . . . . . . . . . . . . . . . . . . 3 5に分類し直します。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 4 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 5 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 5 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1。 引用規格. . . . . . . . . . . . . . . . . . 5 8.2。 有益な参照. . . . . . . . . . . . . . . . . 6作者のアドレスの.6の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 7
Volz Standards Track [Page 1] RFC 3942 Reclassifying DHCPv4 Options November 2004
オプション2004年11月にDHCPv4に分類し直すフォルツ標準化過程[1ページ]RFC3942
1. Introduction
1. 序論
The DHCPv4 [RFC2131] publicly defined options range, options 1 - 127, is nearly used up. Efforts such as [RFC3679] help extend the life of this space, but ultimately the space will be exhausted.
DHCPv4公的に定義された[RFC2131]オプション範囲(オプション1--127)はほとんど使いきられます。 [RFC3679]などの努力は、このスペースの人生を伸ばすのを助けますが、結局、スペースは消耗するでしょう。
This document reclassifies much of the site-specific option range, which has not been widely used for its original intended purpose, to extend the publicly defined options space.
このドキュメントは、公的に定義されたオプションスペースを広げるためにサイト特有のオプション範囲の大部分に分類し直します。(範囲はオリジナルの本来の目的に広く使用されていません)。
2. Requirements Notation
2. 要件記法
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Background
3. バックグラウンド
The DHCP option space (0 - 255) is divided into two ranges [RFC2132]:
DHCPオプションスペース(0--255)は2つの範囲[RFC2132]に分割されます:
1. 1 - 127 are publicly defined options, now allocated in accordance
with [RFC2939].
1. 1--127は[RFC2939]に応じて現在割り当てられている公的に定義されたオプションです。
2. 128 - 254 are site-specific options.
2. 128--254はサイト特有のオプションです。
Options 0 (pad) and 255 (end) are special and defined in [RFC2131].
オプション0(パッド)と255(終わる)は、特別で[RFC2131]で定義されています。
3.1. Publicly Defined Options Range
3.1. 公的に定義されたオプション範囲
The publicly defined options space (1 - 127) is nearly exhausted. Recent work [RFC3679] will buy more time, as several allocated but unused option codes have been reclaimed. A review could be made from time to time to determine whether there are other option codes that can be reclaimed.
公的に定義されたオプションスペース(1--127)はほとんど消耗しています。 いくつかの割り当てられましたが、未使用のオプションコードが取り戻されたとき、近作[RFC3679]はもっと時間を稼ぐでしょう。 取り戻すことができる他のオプションコードがあるかどうか決定するために時々レビューをすることができました。
A longer-term solution to the eventual exhaustion of the publicly defined options space is desired. The DHC WG evaluated several solutions:
公的に定義されたオプションスペースの最後の疲労困憊の、より長い期間ソリューションは望まれています。 DHC WGはいくつかの解決策を評価しました:
1. Using options 126 and 127 to carry 16-bit options as originally
proposed by Ralph Droms in late 1996. However, this significantly
penalizes the first option assigned to this new space, as it
requires implementing the 16-bit option support. Because of this,
options 126 and 127 have been reclaimed [RFC3679].
1. 同じくらい元々16ビットのオプションを運ぶのにオプション126と127を使用するのは1996年後半にラルフDromsで提案しました。 しかしながら、これは16ビットのオプションサポートを実行するのが必要であるのでこの新しいスペースに割り当てられた第1の選択をかなり罰します。 これのために、オプション126と127は取り戻されました[RFC3679]。
2. Using a new magic cookie and 16-bit option code format. However,
this proposal
2. 新しい魔法のクッキーと16ビットのオプションコード形式を使用します。 しかしながら、この提案
Volz Standards Track [Page 2] RFC 3942 Reclassifying DHCPv4 Options November 2004
オプション2004年11月にDHCPv4に分類し直すフォルツ標準化過程[2ページ]RFC3942
* penalizes the first option assigned to this new space, as it
requires significant changes to clients, servers, and relay
agents,
* クライアント、サーバ、および中継エージェントへの著しい変化を必要とするのでこの新しいスペースに割り当てられた第1の選択を罰します。
* could adversely impact existing clients, servers, and relay
agents that fail to properly check the magic cookie value,
* 逆に、適切に魔法のクッキー値をチェックしない既存のクライアント、サーバ、および中継エージェントに影響を与えることができました。
* requires support of both message formats for the foreseeable
future, and
* そして予見できる未来の両方のメッセージ・フォーマットのサポートが必要である。
* requires clients to send multiple DHCPDISCOVER messages -- one
for each magic cookie.
* クライアントがメッセージ--1つにそれぞれの魔法のクッキーに複数のDHCPDISCOVERに行かせるのが必要です。
3. Reclassifying a portion of the site-specific option codes as
publicly defined. The impact is minimal, as only those sites
presently using options in the reclassified range need to renumber
their options.
3. 公的に定義されているとしてサイト特有のオプションコードの部分に分類し直します。 現在分類し直された範囲でオプションを使用するそれらのサイトだけが、彼らのオプションに番号を付け替えさせる必要があるとき、衝撃は最小限です。
3.2. Site-Specific Options Range
3.2. サイト特有のオプション範囲
The site-specific option range is rather large (127 options in all) and little used. The original intent of the site-specific option range was to support local (to a site) configuration options, and it is difficult to believe a site would need 127 options for this purpose. Further, many DHCP client implementations do not provide a well documented means to request site-specific options from a server or to allow applications to extract the returned option values.
サイト特有のオプション範囲は、使用されていた状態でかなり大きくて(全部で127のオプション)、小さいです。 サイト特有のオプション範囲の当初の意図がローカル(サイトへの)の設定オプションをサポートすることであり、サイトがこのために127のオプションを必要とすると信じているのは難しいです。 さらに、多くのDHCPクライアント実現はサーバからサイト特有のオプションを要求するか、またはアプリケーションが返されたオプション価値を抽出するのを許容するよく記録された手段を提供しません。
Some vendors have made use of site-specific option codes that violate the intent of the site-specific options, as the options are used to configure features of their products and thus are specific to many sites. This usage could potentially cause problems if a site that has been using the same site-specific option codes for other purposes deploys products from one of the vendors, or if two vendors pick the same site-specific options.
いくつかの業者がサイト特有のオプションの意図に違反するサイト特有のオプションコードを利用しました、オプションは、それらの製品の特徴を構成するのに使用されて、その結果、多くのサイトに特定です。 他の目的に同じサイト特有のオプションコードを使用しているサイトが業者のひとりからの製品を配備するか、または2つの業者が同じサイト特有のオプションを選ぶなら、この用法は潜在的に問題を起こすかもしれません。
4. Reclassifying Options
4. オプションに分類し直します。
The site-specific option codes 128 to 223 are hereby reclassified as publicly defined options. This leaves 31 site-specific options, 224 to 254.
サイト特有のオプションコード128〜223は公的に定義されたオプションとしてこれにより分類し直されます。 これは31のサイト特有のオプション、224〜254を残します。
To allow vendors that have made use of site-specific options within the reclassified range to publish their option usage and to request an official assignment of the option number to that usage, the following procedure will be used to reclassify these options:
分類し直された範囲の中でサイト特有のオプションを利用した業者がそれらのオプション用法を発行して、オプション番号の公式の課題をその用法に要求するのを許容すると、以下の手順はこれらのオプションに分類し直すのに用いられるでしょう:
Volz Standards Track [Page 3] RFC 3942 Reclassifying DHCPv4 Options November 2004
オプション2004年11月にDHCPv4に分類し直すフォルツ標準化過程[3ページ]RFC3942
1. The reclassified options (128 to 223) will be placed in the
"Unavailable" state by IANA. These options are not yet available
for assignment to publicly defined options.
1. 分類し直されたオプション(128〜223)はIANAによって「入手できません、な」状態に置かれるでしょう。 これらのオプションはまだ公的に定義されたオプションへの課題に利用可能ではありません。
2. Vendors that currently use one or more of the reclassified options
have 6 months following this RFC's publication date to notify the
DHC WG and IANA that they are using particular options numbers and
agree to document that usage in an RFC. IANA will move these
options from the "Unavailable" to "Tentatively Assigned" state.
2. 特定のオプション番号を使用しているようにDHC WGとIANAに通知して、その用法をRFCに記録するのに同意するためにこのRFCの公表日付に従って、現在分類し直されたオプションの1つ以上を使用する業者が6カ月になります。 IANAはこれらの「入手できません、な」状態から「試験的に割り当てられた」状態までのオプションを動かすでしょう。
Vendors have 18 months from this RFC's publication date to start
the documentation process by submitting an Internet-Draft.
業者には、インターネット草稿を提出することによってドキュメンテーションの過程を始めるために、このRFCの公表日付から18カ月があります。
NOTE: If multiple vendors of an option number come forward and can
demonstrate that their usage is in reasonably wide use, none of
the vendors will be allowed to keep the current option number, and
they MUST go through the normal process of getting a publicly
assigned option [RFC2939].
以下に注意してください。 オプション番号の複数の業者が、進み出て、彼らの用法が合理的に広く使用中であることを示すことができると、業者のだれも現在のオプション番号を保つことができないでしょう、そして、彼らは公的に割り当てられたオプション[RFC2939]を得る正常な過程に直面しなければなりません。
3. Any options still classified as "Unavailable" 6 months after the
RFC publication date will be moved to the "Unassigned" state by
IANA. These options may then be assigned to any new publicly
defined options in accordance with [RFC2939].
3. RFC公表日の6カ月後「入手できません」としてまだ分類されていたどんなオプションもIANAによって「割り当てられなかった」状態に動かされるでしょう。 そして、[RFC2939]に従って、これらのオプションはどんな新しい公的に定義されたオプションにも割り当てられるかもしれません。
4. For those options in the "Tentatively Assigned" state, vendors
have 18 months following this RFC's publication date to submit an
Internet-Draft documenting the option. The documented usage MUST
be consistent with the existing usage. When the option usage is
published as an RFC, IANA will move the option to the "Assigned"
state.
4. 「試験的に割り当てられた」状態のそれらのオプションのために、オプションを記録しながらインターネット草稿を提出するためにこのRFCの公表日付に従って、業者には18カ月があります。 記録された用法は既存の用法と一致しているに違いありません。 オプション用法がRFCとして発行されるとき、IANAはオプションを「割り当てられた」状態に動かすでしょう。
If no Internet-Draft is published within the 18 months or should
one of these Internet-Drafts expire after the 18 months, IANA will
move the option to the "Unassigned" state, and the option may then
be assigned to any new publicly defined options in accordance with
[RFC2939].
インターネット草稿が全く18カ月以内に発表されないか、またはこれらのインターネット草稿の1つが18カ月後に期限が切れると、IANAはオプションを「割り当てられなかった」状態に動かすでしょう、そして、次に、[RFC2939]に従って、オプションはどんな新しい公的に定義されたオプションにも割り当てられるかもしれません。
Sites presently using site-specific option codes within the reclassified range SHOULD take steps to renumber these options to values within the remaining range. If a site needs more than 31 site-specific options, the site must switch to using suboptions, as has been done for other options, such as the Relay Agent Information Option [RFC3046].
現在分類し直された範囲SHOULDの中でサイト特有のオプションコードを使用するサイトは、残っている範囲の中でこれらのオプションに値に番号を付け替えさせるために手を打ちます。 サイトが31以上のサイト特有のオプションを必要とするなら、サイトは「副-オプション」を使用するのに切り替わらなければなりません、別の選択肢のためにしたように、Relayエージェント情報Option[RFC3046]などのように。
5. Security Considerations
5. セキュリティ問題
This document in and by itself provides no security, nor does it impact existing DCHP security as described in [RFC2131].
それ自体とそれ自体でこのドキュメントはセキュリティを全く提供しません、そして、それは[RFC2131]で説明されるように既存のDCHPセキュリティに影響を与えません。
Volz Standards Track [Page 4] RFC 3942 Reclassifying DHCPv4 Options November 2004
オプション2004年11月にDHCPv4に分類し直すフォルツ標準化過程[4ページ]RFC3942
6. IANA Considerations
6. IANA問題
IANA is requested to
IANAは要求されています。
1. expand the publicly defined DHCPv4 options space from 1 - 127 to 1
- 223. The new options (128 - 223) are to be listed as
"Unavailable" and MUST NOT be assigned to any publicly defined
options.
1. 公的に定義されたDHCPv4オプションスペースを1--127から1--223に広げてください。 新しいオプション(128--223)が「入手できません」として記載することであり、どんな公的に定義されたオプションにも割り当ててはいけません。
2. receive notices from vendors that have been using one or more of
the options in the 128-223 range that they are using the option
and are willing to document that usage. IANA will list these
options as "Tentatively Assigned".
2. その用法を記録することを望んでいた状態でそれらがオプションを使用していて、ある128-223範囲でのオプションの1つ以上を使用している業者から通知を受け取ってください。 IANAは、これらのオプションが「試験的に割り当てられる」と記載するでしょう。
3. change the listing of any options listed as "Unavailable" to
"Available" 6 months from this RFC's publication date. These
options may now be assigned in accordance with [RFC2939].
3. このRFCの公表から「利用可能な」6カ月でデートするために「入手できません」として記載されたどんなオプションのリストも変えてください。 [RFC2939]に従って、これらのオプションは現在、割り当てられるかもしれません。
4. change the listing of any options listed as "Tentatively-Assigned"
to "Unavailable" 18 months from this RFC's publication date and
periodically thereafter as long as there is an option listed as
"Tentatively-Assigned", if no un-expired Internet-Draft exists
documenting the usage.
4. ある限り、その後「試験的に割り当てられる」としてこのRFCの公表日付から18カ月と定期的に「入手できません」記載されたどんなオプションのリストも変えてください、どんな満期になっていないインターネット草稿も用法を記録しながら存在していないなら。
7. Acknowledgements
7. 承認
Many thanks to Ralph Droms and Ted Lemon for their valuable input and earlier work on the various alternatives.
彼らの貴重な入力のためにラルフDromsとテッドLemonをありがとうございます、前に様々な代替手段に取り組んでください。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[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月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC2132] アレクサンダーとS.とR.Droms、「DHCPオプションとBOOTP業者拡大」、RFC2132、1997年3月。
[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition
of New DHCP Options and Message Types", BCP 43, RFC 2939,
September 2000.
[RFC2939]Droms、R.、「新しいDHCPオプションの定義のための手順とIANAガイドラインとメッセージはタイプします」、BCP43、RFC2939、2000年9月。
Volz Standards Track [Page 5] RFC 3942 Reclassifying DHCPv4 Options November 2004
オプション2004年11月にDHCPv4に分類し直すフォルツ標準化過程[5ページ]RFC3942
8.2. Informative References
8.2. 有益な参照
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[RFC3046] パトリック、M.、「DHCP中継エージェント情報オプション」、RFC3046、2001年1月。
[RFC3679] Droms, R., "Unused Dynamic Host Configuration Protocol
(DHCP) Option Codes", RFC 3679, January 2004.
[RFC3679] Droms、R.、「未使用のDynamic Host Configuration Protocol(DHCP)オプションコード」、RFC3679、2004年1月。
Author's Address
作者のアドレス
Bernard Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
バーナードフォルツシスコシステムズInc.1414マサチューセッツAve。 Boxborough、MA01719米国
Phone: +1 978 936 0382 EMail: volz@cisco.com
以下に電話をしてください。 +1 0382年の978 936メール: volz@cisco.com
Volz Standards Track [Page 6] RFC 3942 Reclassifying DHCPv4 Options November 2004
オプション2004年11月にDHCPv4に分類し直すフォルツ標準化過程[6ページ]RFC3942
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Volz Standards Track [Page 7]
フォルツ標準化過程[7ページ]
一覧
スポンサーリンク
