RFC3011 日本語訳

Network Working Group                                          G. Waters
Request for Comments: 3011                               Nortel Networks
Category: Standards Track                                  November 2000

水域がコメントのために要求するワーキンググループG.をネットワークでつないでください: 3011 ノーテルはカテゴリをネットワークでつなぎます: 標準化過程2000年11月

               The IPv4 Subnet Selection Option for DHCP

DHCPのためのIPv4サブネット選択オプション

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 (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

Abstract

要約

   This memo defines a new Dynamic Host Configuration Protocol (DHCP)
   option for selecting the subnet on which to allocate an address.
   This option would override a DHCP server's normal methods of
   selecting the subnet on which to allocate an address for a client.

このメモはアドレスを割り当てるサブネットを選択するための新しいDynamic Host Configuration Protocol(DHCP)オプションを定義します。 このオプションはDHCPサーバのクライアントのためにアドレスを割り当てるサブネットを選択する正常なメソッドをくつがえすでしょう。

Table of Contents

目次

   1. Introduction..................................................1
   1.1. Motivational Example........................................2
   2. Subnet Selection Option Definition............................3
   3. Intellectual Property.........................................4
   4. IANA Considerations...........................................4
   5. Acknowledgements..............................................5
   6. Security Considerations.......................................5
   7. References....................................................5
   8. Editor's Addresses............................................6
   9. Full Copyright Statement......................................7

1. 序論…1 1.1. 動機づけの例…2 2. サブネット選択オプション定義…3 3. 知的所有権…4 4. IANA問題…4 5. 承認…5 6. セキュリティ問題…5 7. 参照…5 8. エディタのアドレス…6 9. 完全な著作権宣言文…7

1. Introduction

1. 序論

   The Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a
   framework for passing configuration information to hosts on a TCP/IP
   network.  RFC 2132 [RFC2132] specifies DHCP option configuration
   information that may be carried in DHCP packets to/from the DHCP
   server and the DHCP client.  This document specifies a new DHCP
   option.

Dynamic Host Configuration Protocol(DHCP)[RFC2131]はTCP/IPネットワークで設定情報をホストに渡すのにフレームワークを提供します。 RFC2132[RFC2132]はDHCPパケットでDHCPサーバとDHCPクライアントからの/まで運ばれるかもしれないDHCPオプション設定情報を指定します。 このドキュメントは新しいDHCPオプションを指定します。

Waters                      Standards Track                     [Page 1]

RFC 3011                Subnet Selection Option            November 2000

サブネット選択オプション2000年11月に標準化過程[1ページ]RFC3011に水をまきます。

   To select the subnet on which to allocate an address, the DHCP server
   determines the subnet from which the request originated, and then
   selects an address on the originating subnet or on a subnet that is
   on the same network segment as the originating subnet.  The subnet
   from which the request originates can be determined by:

アドレスを割り当てるサブネットを選択するために、DHCPサーバは要求が起因するサブネットと同じネットワークセグメントにある起因するサブネットかサブネットに関するアドレスを溯源して、次に選択するサブネットを決定します。 要求が起因するサブネットは以下で決定できます。

   o Using the subnet address of the giaddr field in the DHCP packet
     header, or if the giaddr field is zero;

o DHCPパケットのヘッダーかそれともgiaddr分野がゼロであるかどうかにgiaddr分野のサブネットアドレスを使用します。

   o Using the subnet address of the local interface on which the DHCP
     server received the packet.

o DHCPサーバがパケットを受けた局所界面のサブネットアドレスを使用します。

   This memo defines a new DHCP option, the subnet selection option,
   which allows the DHCP client to specify the subnet on which to
   allocate an address.  This option takes precedence over the methods
   that the DHCP server uses to determine the subnet on which to select
   an address.

このメモは新しいDHCPオプション、DHCPクライアントがアドレスを割り当てるサブネットを指定できるサブネット選択オプションを定義します。 このオプションはDHCPサーバがアドレスを選択するサブネットを決定するのに使用するメソッドの上で優先します。

   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]で説明されるように本書では解釈されることであるべきですか?

1.1. Motivational Example

1.1. 動機づけの例

   An example of where this option could be useful is in a device (e.g.:
   a RAS device) that is allocating addresses on behalf of its clients.
   In this case the device would be allocating addresses through DHCP
   and then managing those addresses among its clients.

このオプションが役に立つかもしれないところに関する例がクライアントを代表してアドレスを割り当てているデバイス(: 例えば、RASデバイス)にあります。 この場合、デバイスは、DHCPを通してアドレスを割り当てて、次に、クライアントの中でそれらのアドレスを管理しているでしょう。

   In this scenario, the device is connected to a private "internal"
   network on which the DHCP server would be located.  The device is
   also connected to one or more service providing "external" networks
   (i.e.: the networks that the device's clients are connected to).
   Furthermore, the internal network is not IP connected to the external
   networks, although inside the device there is connectivity between
   the internal and external networks (e.g.: though the backplane).

このシナリオでは、デバイスはDHCPサーバが見つけられている私設の「内部」のネットワークに接続されます。 また、デバイスは「外部」のネットワーク(: すなわち、デバイスのクライアントが接続されるネットワーク)を提供する1つ以上のサービスに接続されます。 もっとも、その上、内部のネットワークは外部のネットワークに接続されたIPではありません、内部の、そして、外部のネットワークの間には、デバイスの中に接続性がありますが(例えば:、バックプレーン)

   Recall that the device is allocating addresses for its clients on the
   external networks and that there is no IP connectivity between the
   internal network and the external networks.  The DHCP requests cannot
   originate from the external networks since packets cannot be routed
   between the external network and the internal network.  Thus, the
   DHCP requests must originate from the internal network.  The problem
   with originating the DHCP requests from the internal network is that
   the DHCP server will allocate addresses on the internal network's
   subnet, when what is required are addresses on the external subnets.
   The subnet selection option provides a solution to this problem.

デバイスがクライアントのために外部のネットワークにアドレスを割り当てていて、内部のネットワークと外部のネットワークの間には、IPの接続性が全くなかったと思い出してください。 DHCP要求は、外部のネットワークと内部のネットワークの間にパケットを発送できないので、外部のネットワークから発することができません。 したがって、DHCP要求は内部のネットワークから発しなければなりません。 内部のネットワークからのDHCP要求を溯源することに関する問題はDHCPサーバが内部のネットワークのサブネットに関するアドレスを割り当てるということです、必要であることが外部のサブネットに関するアドレスであるときに。 サブネット選択オプションはこの問題に解決法を提供します。

Waters                      Standards Track                     [Page 2]

RFC 3011                Subnet Selection Option            November 2000

サブネット選択オプション2000年11月に標準化過程[2ページ]RFC3011に水をまきます。

   The device would send its DHCP request on the internal subnet, but
   would include the subnet selection option containing the address of
   the external subnet on which it requires the address.  The subnet
   selection option instructs the DHCP server to allocate the address on
   the requested subnet as opposed to the normal operation of allocating
   the address on the subnet from which the DHCP request originated.

デバイスは、DHCP要求を内部サブネットに送るでしょうが、それがアドレスを必要とする外部のサブネットのアドレスを含むサブネット選択オプションを含んでいるでしょう。 サブネット選択オプションは、DHCP要求が起因したサブネットに関するアドレスを割り当てる通常操作と対照的に要求されたサブネットに関するアドレスを割り当てるようDHCPサーバに命令します。

2. Subnet Selection Option Definition

2. サブネット選択オプション定義

   The subnet selection option is a DHCP option.  The option contains a
   single IPv4 address that is the address of a subnet.  The value for
   the subnet address is determined by taking any IPv4 address on the
   subnet and ANDing that address with the subnet mask (i.e.: the
   network and subnet bits are left alone and the remaining (address)
   bits are set to zero).  When the DHCP server is configured to respond
   to this option, is allocating an address, and this option is present
   then the DHCP server MUST allocate the address on either:

サブネット選択オプションはDHCPオプションです。 オプションはサブネットのアドレスであるただ一つのIPv4アドレスを含んでいます。 サブネットアドレスがあるので、値はサブネットマスクで(: すなわち、ネットワークとビットが単独で残されて、合わせてください残っている(アドレス)ビットが設定されるゼロサブネット)を扱うサブネットとANDingに関するどんなIPv4アドレスも取りながら、自決しました。 DHCPサーバがこのオプションに応じるために構成されて、割り当てがアドレスであり、このオプションが存在していて、次に、DHCPサーバがどちらかに関するアドレスを割り当てなければならないとき:

   o the subnet specified in the subnet selection option, or;

o または、サブネットがサブネット選択オプションで指定した、。

   o a subnet on the same network segment as the subnet specified in the
     subnet selection option.

o サブネットと同じネットワークセグメントに関するサブネットはサブネット選択オプションで指定しました。

   The format of the option is:

オプションの形式は以下の通りです。

        Code   Len        IPv4 Address
       +-----+-----+-----+-----+-----+-----+
       | 118 |  4  | A1  | A2  | A3  | A4  |
       +-----+-----+-----+-----+-----+-----+

レンIPv4が+であると扱うコード-----+-----+-----+-----+-----+-----+ | 118 | 4 | A1| A2| A3| A4| +-----+-----+-----+-----+-----+-----+

   Servers configured to support this option MUST return an identical
   copy of the option to any client that sends it, regardless of whether
   or not the client requests the option in a parameter request list.
   Clients using this option MUST discard DHCPOFFER or DHCPACK packets
   that do not contain this option.

このオプションをサポートするために構成されたサーバはそれを送るどんなクライアントにもオプションの同一の複製物を返さなければなりません、クライアントがパラメタ要求リストにおけるオプションを要求するかどうかにかかわらず。 このオプションを使用しているクライアントはこのオプションを含まないDHCPOFFERかDHCPACKパケットを捨てなければなりません。

   This option does not require changes to operations or features of the
   DHCP server other than to select the subnet on which to allocate an
   address.  For example, the handling of DHCPDISCOVER for an unknown
   subnet should continue to operate unchanged.

このオプションはアドレスを割り当てるサブネットを選択する以外のDHCPサーバの操作か特徴に釣り銭がいません。 例えば、未知のサブネットのためのDHCPDISCOVERの取り扱いは、変わりがない状態で作動し続けるべきです。

   When this option is present and the server is configured to support
   this option, the server MUST NOT offer an address that is not on the
   requested subnet or network segment.  Servers that do not understand
   this option will allocate an address using their normal algorithms
   and will not return this option in the DHCPOFFER or DHCPACK.  In this
   case the client will discard the DHCPOFFER or DHCPACK.  Servers that
   understand this option but are administratively configured to ignore

このオプションが存在していて、サーバがこのオプションをサポートするために構成されるとき、サーバは要求されたサブネットかネットワークセグメントにないアドレスを提供してはいけません。 このオプションを理解していないサーバが、それらの正常なアルゴリズムを使用することでアドレスを割り当てて、DHCPOFFERかDHCPACKのこのオプションを返さないでしょう。 この場合、クライアントはDHCPOFFERかDHCPACKを捨てるでしょう。 ゆだねますが、これが無視するために行政上構成されるのを理解しているサーバ

Waters                      Standards Track                     [Page 3]

RFC 3011                Subnet Selection Option            November 2000

サブネット選択オプション2000年11月に標準化過程[3ページ]RFC3011に水をまきます。

   the option MUST ignore the option, use their normal algorithms to
   allocate an address, and MUST NOT return this option in the DHCPOFFER
   or DHCPACK.  In this case the client will discard the DHCPOFFER or
   DHCPACK.

オプションは、オプションを無視しなければならなくて、アドレスを割り当てるのにそれらの正常なアルゴリズムを使用して、DHCPOFFERかDHCPACKのこのオプションを返してはいけません。 この場合、クライアントはDHCPOFFERかDHCPACKを捨てるでしょう。

   During an address renew, the DHCP server may send a DHCPACK directly
   to the allocated address, however packets from the DHCP server may
   not be routable to the address.  Thus, in all packets that the DHCP
   client sends that contain the subnet selection option, the giaddr
   field in the BOOTP header MUST be set to an IPv4 address on which the
   DHCP client will accept DHCP packets (e.g.: the address on the subnet
   connected to the internal network).

アドレスの間、更新してください、そして、DHCPサーバは直接割り当てられたアドレスにDHCPACKを送るかもしれなくて、しかしながら、DHCPサーバからのパケットはアドレスに発送可能である必要はありません。 このようにして、そして、全部で、DHCPクライアントがそれを送るパケットはサブネット選択オプションを含んでいて、DHCPクライアントがDHCPパケットを受け入れるIPv4アドレスにBOOTPヘッダーのgiaddr分野を設定しなければなりません(: 例えばサブネットに関するアドレスは内部のネットワークに接続しました)。

   The IPv4 address to which a DHCP server sends a reply to MUST be the
   same as it would chose when this option is not present.

IPv4が扱う、このオプションが選ばなかったとき、DHCPサーバがでなければならない返信するように返信するものに、プレゼントは選ばれていました。

3. Intellectual Property

3. 知的所有権

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.

IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。

   Copies of claims of rights made available for publication 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 Secretariat.

権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可がimplementersによるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。

4. IANA Considerations

4. IANA問題

   IANA has assigned a value of 118 for the DHCP option code described
   in this document.

IANAは本書では説明されたDHCPオプションコードのために118の値を割り当てました。

Waters                      Standards Track                     [Page 4]

RFC 3011                Subnet Selection Option            November 2000

サブネット選択オプション2000年11月に標準化過程[4ページ]RFC3011に水をまきます。

5. Acknowledgements

5. 承認

   This document is the result of work undertaken the by DHCP working
   group.  Thanks to Ted Lemon, Tim Aston and Ralph Droms for their
   helpful comments in this work.

このドキュメントが引き受けられた仕事の結果である、DHCPワーキンググループで。 おかげに、これの彼らの役に立つコメントのためのテッドLemon、ティム・アストンとラルフDromsは働いています。

   W. Mark Townsley and Pratik Gupta originally published a subnet
   selection option Internet Draft in July 1997. The work in this
   document was not based on the original work but it does achieve the
   same goals.

W.マークTownsleyとPratikグプタは1997年7月に元々、サブネット選択オプションインターネットDraftを発行しました。 仕事は本書ではオリジナルの仕事に基づいて同じ目標を達成するということではありませんでした。

6. Security Considerations

6. セキュリティ問題

   DHCP currently provides no authentication or security mechanisms.
   Potential exposures to attack are discussed is section 7 of the
   protocol specification [RFC2131].

DHCPは現在、どんな認証もセキュリティー対策も提供しません。攻撃する潜在被曝は議論しているのが、プロトコル仕様[RFC2131]のセクション7であるということです。

   The subnet selection option allows for the DHCP client to specify the
   subnet on which to allocate an address.  This would allow a client to
   perform a more complete address-pool exhaustion attack since the
   client would no longer be restricted to attacking address-pools on
   just its local subnet.

サブネット選択オプションは、DHCPクライアントがアドレスを割り当てるサブネットを指定するのを許容します。 クライアントはもうまさしく地方のサブネットでアドレスプールを攻撃するのに制限されないでしょう、したがって、これで、クライアントが、より完全なアドレスプール疲労困憊攻撃を実行できるでしょう。

   Servers that implement the subnet selection option MUST by default
   disable use of the feature; it must specifically be enabled through
   configuration.  Moreover, a server SHOULD provide the ability to
   selectively enable use of the feature under restricted conditions,
   e.g., by enabling use of the option only from explicitly configured
   client-ids, enabling its use only by clients on a particular subnet,
   or restricting the subnets (as indicated in the subnet selection
   option) from which addresses may be requested.

サブネット選択がオプションであると実装するサーバはデフォルトで特徴の使用を無効にしなければなりません。 構成を通して明確にそれを可能にしなければなりません。 そのうえ、どのアドレスが要求されるかもしれないかからSHOULDが制限される下で選択的に特徴の使用を可能にする能力を提供するサーバは例えば、オプションの可能な使用で明らかに構成されたクライアントイド、単に特定のサブネットのクライアントによる使用を可能にするか、または制限からのサブネットだけを条件とさせます(サブネット選択オプションにみられるように)。

7. References

7. 参照

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

Waters                      Standards Track                     [Page 5]

RFC 3011                Subnet Selection Option            November 2000

サブネット選択オプション2000年11月に標準化過程[5ページ]RFC3011に水をまきます。

8. Editor's Address

8. エディタのアドレス

   Glenn Waters
   Nortel Networks
   310-875 Carling Avenue,
   Ottawa, Ontario K1S 5P1
   Canada

グレンWatersノーテルネットワーク310-875Carlingアベニュー、オタワ、オンタリオK1S 5P1カナダ

   Phone:  +1 613-765-0249
   EMail:  gww@nortelnetworks.com

以下に電話をしてください。 +1 613-765-0249 メールしてください: gww@nortelnetworks.com

Waters                      Standards Track                     [Page 6]

RFC 3011                Subnet Selection Option            November 2000

サブネット選択オプション2000年11月に標準化過程[6ページ]RFC3011に水をまきます。

9.  Full Copyright Statement

9. 完全な著作権宣言文

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

Copyright(C)インターネット協会(2000)。 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機能のための基金は現在、インターネット協会によって提供されます。

Waters                      Standards Track                     [Page 7]

標準化過程に水をまきます。[7ページ]