RFC2610 日本語訳

Network Working Group                                         C. Perkins
Request for Comments: 2610                                    E. Guttman
Category: Standards Track                               Sun Microsystems
                                                               June 1999

コメントを求めるワーキンググループC.パーキンス要求をネットワークでつないでください: 2610年のE.Guttmanカテゴリ: 標準化過程サン・マイクロシステムズ1999年6月

               DHCP Options for Service Location Protocol

サービス位置のプロトコルのための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 (1999).  All Rights Reserved.

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

Abstract

要約

   The Dynamic Host Configuration Protocol provides a framework for
   passing configuration information to hosts on a TCP/IP network.
   Entities using the Service Location Protocol need to find out the
   address of Directory Agents in order to transact messages.  Another
   option provides an assignment of scope for configuration of SLP User
   and Service Agents.

Dynamic Host Configuration ProtocolはTCP/IPネットワークで設定情報をホストに渡すのにフレームワークを提供します。 Service Locationプロトコルを使用する実体は、メッセージを商取引するためにディレクトリエージェントのアドレスを見つける必要があります。 別のオプションはSLP UserとServiceエージェントの構成に範囲の課題を提供します。

1. Introduction

1. 序論

   The Dynamic Host Configuration Protocol [2] provides a framework for
   passing configuration information to hosts on a TCP/IP network.
   Entities using the Service Location Protocol, Version 2 [3] and
   Service Location Protocol, Version 1 [4] need to obtain the address
   of Directory Agents and Scope configuration.  The Service Location
   Protocol (SLP) provides a default configuration for Scopes and
   Directory Agents may be discovered using multicast or broadcast.  It
   is useful in a larger deployment to be able to configure SLP Agents
   using DHCP, so as to centralize the administration and to deploy SLP
   in networks where multicast routing is not available.

Dynamic Host Configuration Protocol[2]はTCP/IPネットワークで設定情報をホストに渡すのにフレームワークを提供します。 Service Locationプロトコル、バージョン2[3]、およびService Locationプロトコルを使用する実体、バージョン1[4]は、ディレクトリエージェントとScope構成のアドレスを得る必要があります。 Service Locationプロトコル(SLP)がデフォルト設定をScopesに供給して、ディレクトリエージェントは、マルチキャストを使用していると発見されるか、または放送されるかもしれません。 より大きい展開では、管理を集結するためにDHCPを使用することでSLPエージェントを構成して、マルチキャストルーティングが利用可能でないネットワークでSLPを配布することができるのは役に立ちます。

   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 [1].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[1]で説明されるように本書では解釈されることであるべきですか?

Perkins & Guttman           Standards Track                     [Page 1]

RFC 2610       DHCP Options for Service Location Protocol      June 1999

サービス位置のためのパーキンスとGuttman標準化過程[1ページ]RFC2610DHCPオプションは1999年6月に議定書を作ります。

2. Introduction

2. 序論

   The DHCP options described below are used to configure Agents using
   the Service Location Protocol, Version 2 [3] and Version 1 [4].

以下で説明されたDHCPオプションはService Locationプロトコル、バージョン2[3]を使用することでエージェントを構成するのにおいて中古、そして、バージョン1[4]です。

   The SLP Directory Agent option is used to configure User Agents and
   Service Agents with the location of Directory Agents in the network.

SLPディレクトリエージェントオプションは、ディレクトリエージェントの位置でネットワークでUserエージェントとServiceエージェントを構成するのに使用されます。

   The SLP Scope Option takes precedence over both default and static
   scope configuration of SLP agents.

SLP Scope OptionはデフォルトとSLPエージェントの静的な範囲構成の両方の上で優先します。

3. SLP Directory Agent Option

3. SLPディレクトリエージェントオプション

   This option specifies the location of one or more SLP Directory
   Agents.

このオプションは1人以上のSLPディレクトリエージェントの位置を指定します。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Code = 78   |    Length     |   Mandatory   |      a1       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      a2       |       a3      |       a4      |      ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード=78| 長さ| 義務的| a1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a2| a3| a4| ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The SLP Directory Agent Option specifies a list of IP addresses for
   Directory Agents.  Directory Agents MUST be listed in order of
   preference, if there is an order of preference.

SLPディレクトリエージェントOptionはIPアドレスのリストをディレクトリエージェントに指定します。 よく使われる順があれば、好みの順にディレクトリエージェントを記載しなければなりません。

   The Length value must include one for the 'Mandatory' byte and
   include four for each Directory Agent address which follows.  Thus,
   the Length minus one of the option MUST always be divisible by 4 and
   has a minimum value of 5.

Length値は、'義務的な'バイトのために1つを含んでいて、従うそれぞれのディレクトリエージェントアドレスのために4を含まなければなりません。 したがって、オプションの1つを引いたLengthはいつも4で分割可能でなければならなく、5の最小値を持っています。

   The address of the Directory Agent is given in network byte order.

ネットワークバイトオーダーでディレクトリエージェントのアドレスを与えます。

   The 'Mandatory' byte in the Directory Agent option may be set to
   either 0 or 1.  If it is set to 1, the SLP User Agent or Service
   Agent so configured MUST NOT employ either active or passive
   multicast discovery of Directory Agents.

ディレクトリエージェントオプションにおける'義務的な'バイトは0か1に設定されるかもしれません。 それが1に設定されるなら、そのように構成されたSLP UserエージェントかServiceエージェントがディレクトリエージェントのアクティブであるか受け身のマルチキャスト発見を使ってはいけません。

   Note that for backward compatibility with some deployed software the
   Mandatory byte MUST NOT be set to any byte value for which the high
   order bit (0x80) is set.

いくつかとの後方の互換性が、ソフトウェアがMandatoryバイトであると配布したので高位のビット(0×80)が設定されるどんなバイト値にもそれを設定してはいけないことに注意してください。

   The Directory Agents listed in this option MUST be configured with
   the a non-empty subset of the scope list that the Agent receiving the
   Directory Agent Option is configured with.  See the notes below.

構成されていて、このオプションで記載されたエージェントがそうしなければならないディレクトリは範囲のa非空の部分集合でそれを記載します。ディレクトリエージェントOptionが構成されるエージェント受信。 以下での注意を見てください。

Perkins & Guttman           Standards Track                     [Page 2]

RFC 2610       DHCP Options for Service Location Protocol      June 1999

サービス位置のためのパーキンスとGuttman標準化過程[2ページ]RFC2610DHCPオプションは1999年6月に議定書を作ります。

   The SLPv2 specification [3] defines how to use this option.

SLPv2仕様[3]はこのオプションを使用する方法を定義します。

4. SLP Service Scope Option

4. SLPサービス範囲オプション

   The scope list is a comma delimited list which indicates the scopes
   that a SLP Agent is configured to use.

範囲リストはSLPエージェントが使用するために構成される範囲を示すコンマの区切られたリストです。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Code = 79   |     Length    |   Mandatory   | <Scope List>...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード=79| 長さ| 義務的| <範囲リスト>… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Length indicates the number of bytes which follow.  Since the
   Scope-List String is encoded using UTF-8 [5] characters, it may be
   the cast that the Length is not the same as the number of characters
   in the Scope-List String.  The Length value must include one for the
   'Mandatory' byte.

Lengthは続くバイト数を示します。 Scope-リストStringがUTF-8[5]キャラクタを使用することでコード化されるので、キャラクタの数と同じくらいではなく、それはScope-リストStringのLengthがそうであるキャストであるかもしれません。 Length値は'義務的な'バイト単位で1つを含まなければなりません。

   The 'Mandatory' byte determines whether SLP Agents override their
   static configuration for scopes with the <Scope List> string provided
   by the option.  This allows DHCP administrators to implement a policy
   of assigning a set of scopes to Agents for service provision.  If the
   Mandatory byte is 0, static configuration takes precedence over the
   DHCP provided scope list.  If the Mandatory byte is 1, the <Scope
   List> provided in this option MUST be used by the SLP Agent.

'義務的な'バイトは、SLPエージェントがオプションで<Scope List>ストリングを提供している状態で範囲のための彼らの静的な構成をくつがえすかどうか決定します。 これで、DHCP管理者はサービス支給のために1セットの範囲をエージェントに割り当てる政策を実施できます。 Mandatoryバイトが0であるなら、静的な構成は範囲リストであるならDHCPの上で優先します。 Mandatoryバイトが1であるなら、SLPエージェントはこのオプションに提供された<Scope List>を使用しなければなりません。

   The Scope List String syntax and usage are defined in the SLPv2
   specification [3].

Scope List String構文と用法はSLPv2仕様[3]に基づき定義されます。

4.1. Zero Length Scope-List String Configuration

4.1. 長さの範囲リストストリング構成がありません。

   A SLP Service Scope Option which indicates a Length of 1 (in other
   words, omitting the <Scope List> string entirely) validly configures
   the SLP User Agent to use "User Selectable Scopes."

確実に1(言い換えれば、<Scope List>ストリングを完全に省略する)のLengthを示すSLP Service Scope Optionは、「ユーザの選択可能な範囲」を使用するためにSLP Userエージェントを構成します。

   The SLP Agent will use the aggregated list of scopes of all known
   DAs.  If no DAs are known, the UA will use SA discovery to determine
   the list of scopes on the network, as defined in  [3].

SLPエージェントはすべての知られているDAsの範囲の集められたリストを使用するでしょう。 DAsが全く知られていないと、UAはネットワークの範囲のリストを決定するのにSA発見を使用するでしょう、[3]で定義されるように。

   Note that this configuration is tantamount to removing all
   centralized control of the scope configuration of hosts on the
   network.  This makes it possible for every User Agent to see every
   service.  This may not be desirable as users may not be able to or
   desire to decide which services are appropriate for them.

この構成がネットワークにおけるホストの範囲構成のすべての集中制御を取り除くのと等しいことに注意してください。 これで、すべてのUserエージェントがあらゆるサービスを見るのが可能になります。 ユーザが、できるか、またはそれらに、どのサービスが適切であるかを決めることを望まないかもしれないようにこれは望ましくないかもしれません。

Perkins & Guttman           Standards Track                     [Page 3]

RFC 2610       DHCP Options for Service Location Protocol      June 1999

サービス位置のためのパーキンスとGuttman標準化過程[3ページ]RFC2610DHCPオプションは1999年6月に議定書を作ります。

5. Security Considerations

5. セキュリティ問題

   If a malicious host is able to insert fraudulent information in
   DHCPOFFER packets sent to a prospective SLP Agent then the SLP Agent
   will be unable to obtain service, or may unwittingly be directed to
   use the incorrect services.

悪意があるホストが将来のSLPエージェントに送られたDHCPOFFERパケットに詐欺的情報を挿入できるなら、SLPエージェントは、サービスを得ることができませんし、また不正確なサービスを利用するよう知らず知らず指示されるかもしれません。

   Many opportunities for denial of service exist.  A service agent
   could find that it might rely on fraudulent or otherwise malicious
   directory agents to advertise its services.  DHCPOFFERs could prevent
   the regular SLP framework from functioning by directing clients to
   not use multicast, to use nonexistent directory agents and so on.

サービスの否定の多くの機会が存在しています。 サービスエージェントは、それがサービスの広告を出すために詐欺的であるかそうでなければ、悪意があるディレクトリエージェントに頼るかもしれないのを見つけることができました。 実在しないディレクトリエージェントなどを使用するのにマルチキャストを使用しないようクライアントに指示することによって、DHCPOFFERsは、通常のSLPフレームワークが機能するのを防ぐかもしれません。

   These difficulties are inherited from the much larger and more
   serious problem, viz.  securing or authenticating any information
   whatsoever from a DHCP server (or client!)  is not possible in common
   DHCP deployments.

これらの困難ははるかに大きくて、より重大な問題から引き継がれて、つまり、DHCPサーバ(または、クライアント!)からの全くどんな情報も機密保護するか、または認証するのが一般的なDHCP展開で可能ではありません。

References

参照

   [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

[2]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。

   [3] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service
       Location Protocol version 2", Work in Progress.

[3] E.Guttman、C.パーキンス、J.Veizades、およびM.デー、「Locationを調整してください、プロトコルバージョン2インチ、ProgressのWork、」

   [4] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service
       Location Protocol", RFC 2165, July 1997.

[4]VeizadesとJ.とGuttmanとE.とパーキンスとC.とS.キャプラン、「サービス位置のプロトコル」、RFC2165、1997年7月。

   [5] Yergeau, F., "UTF-8, a transformation format of unicode and ISO
       10646", RFC 2279, October 1998.

[5]Yergeau、1998年10月のF.、「UTF-8、ユニコードとISO10646の変換形式」RFC2279。

Perkins & Guttman           Standards Track                     [Page 4]

RFC 2610       DHCP Options for Service Location Protocol      June 1999

サービス位置のためのパーキンスとGuttman標準化過程[4ページ]RFC2610DHCPオプションは1999年6月に議定書を作ります。

Authors' Addresses

作者のアドレス

   Charles E. Perkins
   Technology Development Group
   Mail Stop MPK15-214
   Sun Microsystems, Inc.
   15 Network Circle
   Menlo Park, CA  94025

チャールズE.パーキンス技術開発グループはメンローパーク、ネットワーク円のカリフォルニア 94025を停止MPK15-214サン・マイクロシステムズ・インク15に郵送します。

   Phone: +1 650-786-6464
   Fax:   +1 650-786-6445
   EMail: Charles.Perkins@Sun.Com
   Web: http://www.svrloc.org/~charliep

以下に電話をしてください。 +1 650-786-6464Fax: +1 650-786-6445 メールしてください: Charles.Perkins@Sun.Com ウェブ: http://www.svrloc.org/~charliep

   Erik Guttman
   Technology Development Group
   Mail Stop UFRA02
   Sun Microsystems, Inc.
   Bahnstr. 2
   74915 Waibstadt, Germany

エリックGuttman技術開発グループは停止UFRA02サン・マイクロシステムズ・インクBahnstrに郵送します。 2 74915Waibstadt、ドイツ

   Phone: +49 7263 911 701
     or:  +1 650 786 5992
   EMail: Erik.Guttman@Sun.Com

以下に電話をしてください。 または、+49 7263 911 701、: +1 5992年の650 786メール: Erik.Guttman@Sun.Com

Perkins & Guttman           Standards Track                     [Page 5]

RFC 2610       DHCP Options for Service Location Protocol      June 1999

サービス位置のためのパーキンスとGuttman標準化過程[5ページ]RFC2610DHCPオプションは1999年6月に議定書を作ります。

Full Copyright Statement

完全な著作権宣言文

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

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

Perkins & Guttman           Standards Track                     [Page 6]

パーキンスとGuttman標準化過程[6ページ]