RFC3361 日本語訳

Network Working Group                                     H. Schulzrinne
Request for Comments: 3361                           Columbia University
Category: Standards Track                                    August 2002

Schulzrinneがコメントのために要求するワーキンググループH.をネットワークでつないでください: 3361年のコロンビア大学カテゴリ: 標準化過程2002年8月

          Dynamic Host Configuration Protocol (DHCP-for-IPv4)
          Option for Session Initiation Protocol (SIP) Servers

セッション開始プロトコル(一口)サーバのためのDynamic Host Configuration Protocol(IPv4のための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 (2002).  All Rights Reserved.

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

Abstract

要約

   This document defines a Dynamic Host Configuration Protocol
   (DHCP-for-IPv4) option that contains a list of domain names or IPv4
   addresses that can be mapped to one or more Session Initiation
   Protocol (SIP) outbound proxy servers.  This is one of the many
   methods that a SIP client can use to obtain the addresses of such a
   local SIP server.

このドキュメントはドメイン名のリストを含むDynamic Host Configuration Protocol(IPv4のためのDHCP)オプションか1つ以上のSession Initiationプロトコル(SIP)の外国行きのプロキシサーバに写像できるIPv4アドレスを定義します。 これはSIPクライアントがそのようなローカルのSIPサーバのアドレスを得るのに使用できる多くのメソッドの1つです。

1.  Terminology

1. 用語

        DHCP client: A DHCP [1] client is an Internet host that uses
             DHCP to obtain configuration parameters such as a network
             address.

DHCPクライアント: DHCP[1]クライアントはネットワーク・アドレスなどの設定パラメータを得るのにDHCPを使用するインターネット・ホストです。

        DHCP server: A DHCP server is an Internet host that returns
             configuration parameters to DHCP clients.

DHCPサーバ: DHCPサーバはDHCPクライアントに設定パラメータを返すインターネット・ホストです。

        SIP server: As defined in RFC 3261 [2].  This server MUST be an
            outbound proxy server, as defined in [3].  In the context of
            this document, a SIP server refers to the host the SIP
            server is running on.

SIPサーバ: RFC3261[2]で定義されるように。 このサーバは[3]で定義されるように外国行きのプロキシサーバであるに違いありません。 このドキュメントの文脈では、SIPサーバはSIPサーバが走っているホストについて言及します。

        SIP client: As defined in RFC 3261.  The client can be a user
            agent client or the client portion of a proxy server.  In
            the context of this document, a SIP client refers to the
            host the SIP client is running on.

SIPクライアント: RFC3261で定義されるように。 クライアントはユーザエージェントのクライアントであるかもしれませんかクライアントがプロキシサーバの部分です。このドキュメントの文脈では、SIPクライアントはSIPクライアントが走っているホストについて言及します。

Schulzrinne                 Standards Track                     [Page 1]

RFC 3361             DHCPv4 Option for SIP Servers           August 2002

Schulzrinne規格は2002年8月に一口サーバのためのRFC3361DHCPv4オプションを追跡します[1ページ]。

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [4].

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

2.  Introduction

2. 序論

   The Session Initiation Protocol (SIP) [2] is an application-layer
   control protocol that can establish, modify and terminate multimedia
   sessions or calls.  A SIP system has a number of logical components:
   user agents, proxy servers, redirect servers and registrars.  User
   agents MAY contain SIP clients, proxy servers always do.

Session Initiationプロトコル(SIP)[2]はマルチメディアセッションを確立して、変更して、終えることができる応用層制御プロトコルであるか呼びます。 SIPシステムには、多くの論理的なコンポーネントがあります: ユーザエージェント(プロキシサーバ)はサーバと記録係を向け直します。 ユーザエージェントはSIPクライアントを含むかもしれなくて、プロキシサーバはいつもします。

   This document specifies a DHCP option [1,5] that allows SIP clients
   to locate a local SIP server that is to be used for all outbound SIP
   requests, a so-called outbound proxy server.  (SIP clients MAY
   contact the address identified in the SIP URL directly, without
   involving a local SIP server.  However in some circumstances, for
   example, when firewalls are present, SIP clients need to use a local
   server for outbound requests.)  This is one of many possible
   solutions for locating the outbound SIP server; manual configuration
   is an example of another.

SIPクライアントはSIP URLで直接特定されたアドレスに連絡するかもしれません、ローカルのSIPサーバにかかわらないで。このドキュメントはSIPクライアントがすべての外国行きのSIP要求(いわゆる外国行きのプロキシサーバ)に使用されることになっているローカルのSIPサーバの場所を見つけることができるDHCPオプション[1、5]を指定します(しかしながら、いくつかの事情では、ファイアウォールが存在しているとき、例えば、SIPクライアントは、外国行きの要求にローカルサーバを使用する必要があります。)。 これは外国行きのSIPサーバの場所を見つけるための多くの可能なソリューションの1つです。 手動の構成は別のものに関する例です。

3.  SIP Server DHCP Option

3. 一口サーバDHCPオプション

   The SIP server DHCP option carries either a 32-bit (binary) IPv4
   address or, preferably, a DNS (RFC 1035 [6]) fully-qualified domain
   name to be used by the SIP client to locate a SIP server.

SIPサーバDHCPオプションは32ビット(2進の)のIPv4アドレスか望ましくはDNSを運びます。(SIPサーバの場所を見つけるのにSIPクライアントによって使用されるべき[6])RFC1035完全修飾ドメイン名。

   The option has two encodings, specified by the encoding byte ('enc')
   that follows the code byte.  If the encoding byte has the value 0, it
   is followed by a list of domain names, as described below (Section
   3.1).  If the encoding byte has the value 1, it is followed by one or
   more IPv4 addresses (Section 3.2).  All implementations MUST support
   both encodings.  The 'Len' field indicates the total number of octets
   in the option following the 'Len' field, including the encoding byte.

オプションはコードバイトに続くコード化バイト('enc')によって指定された2encodingsを持っています。 コード化バイトに値0があるなら、ドメイン名のリストはそれのあとに続いています、(セクション3.1)の下で説明されるように。 コード化バイトに値1があるなら、1つ以上のIPv4アドレス(セクション3.2)がそれのあとに続いています。 すべての実装が両方のencodingsをサポートしなければなりません。 コード化バイトを含む'レン'野原に続いて、'レン'分野はオプションにおける、八重奏の総数を示します。

   A DHCP server MUST NOT mix the two encodings in the same DHCP
   message, even if it sends two different instances of the same option.
   Attempts to do so would result in incorrect client behavior as DHCP
   processing rules call for the concatenation of multiple instances of
   an option into a single option prior to processing the option [7].

DHCPサーバは同じDHCPメッセージで2encodingsを混ぜてはいけません、同じオプションの2つの異なったインスタンスを送っても。 DHCP処理規則が、処理の前のただ一つのオプションへのオプションの複数のインスタンスの連結のためにオプションを[7]と呼ぶとき、そうする試みは不正確なクライアントの振舞いをもたらすでしょう。

   The code for this option is 120.

このオプションのためのコードは120です。

Schulzrinne                 Standards Track                     [Page 2]

RFC 3361             DHCPv4 Option for SIP Servers           August 2002

Schulzrinne規格は2002年8月に一口サーバのためのRFC3361DHCPv4オプションを追跡します[2ページ]。

3.1 Domain Name List

3.1 ドメイン名リスト

   If the 'enc' byte has a value of 0, the encoding byte is followed by
   a sequence of labels, encoded according to Section 3.1 of RFC 1035
   [6], quoted below:

'enc'バイトに0の値があるなら、以下で引用されたRFC1035[6]のセクション3.1によると、コード化されたラベルの系列はコード化バイトのあとに続いています:

         Domain names in messages are expressed in terms of a sequence
         of labels.  Each label is represented as a one octet length
         field followed by that number of octets.  Since every domain
         name ends with the null label of the root, a domain name is
         terminated by a length byte of zero.  The high order two bits
         of every length octet must be zero, and the remaining six bits
         of the length field limit the label to 63 octets or less.  To
         simplify implementations, the total length of a domain name
         (i.e., label octets and label length octets) is restricted to
         255 octets or less.

メッセージのドメイン名はラベルの系列で言い表されます。 その数の八重奏で1つの八重奏長さの野原が続いたので、各ラベルは表されます。 あらゆるドメイン名が根のヌルラベルで終わるので、ドメイン名はゼロの長さのバイト終えられます。 あらゆる長さの八重奏の高位2ビットはゼロであるに違いありません、そして、長さの分野の残っている6ビットはラベルを63以下の八重奏に制限します。 実装を簡素化するために、ドメイン名(すなわち、ラベル八重奏とラベル長さの八重奏)の全長は255以下の八重奏に制限されます。

   RFC 1035 encoding was chosen to accommodate future internationalized
   domain name mechanisms.

RFC1035コード化は、将来の国際化ドメイン名メカニズムに対応するために選ばれました。

   The minimum length for this encoding is 3.

このコード化のための最小の長さは3です。

   The option MAY contain multiple domain names, but these SHOULD refer
   to different NAPTR records, rather than different A records.  The
   client MUST try the records in the order listed, applying the
   mechanism described in Section 4.1 of RFC 3263 [3] for each.  The
   client only resolves the subsequent domain names if attempts to
   contact the first one failed or yielded no common transport protocols
   between client and server or denote a domain administratively
   prohibited by client policy.

オプションは複数のドメイン名を含むかもしれませんが、これらのSHOULDは異なったA記録よりむしろ異なったNAPTR記録を示します。 クライアントはそれぞれのためのRFC3263[3]のセクション4.1で説明されたメカニズムを適用して、リストアップされたオーダーにおける記録を試みなければなりません。 最初のものに連絡する試みが失敗するか、クライアントとサーバの間のどんな一般的なトランスポート・プロトコルももたらさないか、またはクライアント方針で行政上禁止されたドメインを指示する場合にだけ、クライアントはその後のドメイン名を決議します。

         Use of multiple domain names is not meant to replace NAPTR and
         SRV records, but rather to allow a single DHCP server to
         indicate outbound proxy servers operated by multiple providers.

NAPTRとSRV記録を置き換えることが意味されるのではなく、複数のドメイン名の使用は、むしろただ一つのDHCPサーバが複数のプロバイダーによって操作された外国行きのプロキシサーバを示すのを許容するために意味されます。

   Clients MUST support compression according to the encoding in Section
   4.1.4 of "Domain Names - Implementation And Specification" [6].

クライアントが中のコード化に従った圧縮にセクション4.1.4をサポートしなければならない、「ドメイン名--、実装と仕様、」 [6]。

         Since the domain names are supposed to be different domains,
         compression will likely have little effect, however.

ドメイン名が異なったドメインであるべきであるので、圧縮には、しかしながら、効果がおそらくほとんどないでしょう。

   If the length of the domain list exceeds the maximum permissible
   within a single option (254 octets), then the domain list MUST be
   represented in the DHCP message as specified in [7].

ドメインリストの長さがただ一つのオプション(254の八重奏)の中で許されている最大を超えているなら、[7]の指定されるとしてのDHCPメッセージにドメインリストを表さなければなりません。

Schulzrinne                 Standards Track                     [Page 3]

RFC 3361             DHCPv4 Option for SIP Servers           August 2002

Schulzrinne規格は2002年8月に一口サーバのためのRFC3361DHCPv4オプションを追跡します[3ページ]。

   The DHCP option for this encoding has the following format:

このコード化のためのDHCPオプションには、以下の形式があります:

        Code  Len   enc   DNS name of SIP server
      +-----+-----+-----+-----+-----+-----+-----+-----+--
      | 120 |  n  |  0  |  s1 |  s2 |  s3 |  s4 | s5  |  ...
      +-----+-----+-----+-----+-----+-----+-----+-----+--

レンenc DNSが命名するSIPサーバ+のコード-----+-----+-----+-----+-----+-----+-----+-----+-- | 120 | n| 0 | s1| s2| s3| s4| s5| ... +-----+-----+-----+-----+-----+-----+-----+-----+--

   As an example, consider the case where the server wants to offer two
   outbound proxy servers, "example.com" and "example.net".  These would
   be encoded as follows:

例と、サーバが2つの外国行きのプロキシサーバ、"example.com"、および"example.net"を提供したがっているケースを考えてください。 これらは以下の通りコード化されるでしょう:

      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      |120|27 | 0 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      +---+---+---+---+---+---+---+---+---+---+---+---+---+ | 7
      |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 | +---+---+---
      +---+---+---+---+---+---+---+---+---+---+

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |120|27 | 0 | 7 |'e'|'x'|'a'|'存在'|'p'|'l'|'e'| 3 |'c'|'o'|'存在'| 0 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+ | 7 |'e'|'x'|'a'|'存在'|'p'|'l'|'e'| 3 |'、'|'e'|'、'| 0 | +---+---+--- +---+---+---+---+---+---+---+---+---+---+

3.2  IPv4 Address List

3.2 IPv4住所録

   If the 'enc' byte has a value of 1, the encoding byte is followed by
   a list of IPv4 addresses indicating SIP outbound proxy servers
   available to the client.  Servers MUST be listed in order of
   preference.

'enc'バイトに1の値があるなら、クライアントにとって、利用可能なSIP外国行きのプロキシサーバを示すIPv4アドレスのリストはコード化バイトのあとに続いています。 好みの順にサーバを記載しなければなりません。

   Its minimum length is 5, and the length MUST be a multiple of 4 plus
   one.  The DHCP option for this encoding has the following format:

最小の長さは5です、そして、長さは4足す1の倍数であるに違いありません。 このコード化のためのDHCPオプションには、以下の形式があります:

       Code   Len   enc   Address 1               Address 2
      +-----+-----+-----+-----+-----+-----+-----+-----+--
      | 120 |  n  |  1  | a1  | a2  | a3  | a4  | a1  |  ...
      +-----+-----+-----+-----+-----+-----+-----+-----+--

コードレンenc Address1Address2+-----+-----+-----+-----+-----+-----+-----+-----+-- | 120 | n| 1 | a1| a2| a3| a4| a1| ... +-----+-----+-----+-----+-----+-----+-----+-----+--

4.  Security Considerations

4. セキュリティ問題

   The security considerations in RFC 2131 [1], RFC 2543 [2] and RFC
   3263 [3] apply.  If an adversary manages to modify the response from
   a DHCP server or insert its own response, a SIP user agent could be
   led to contact a rogue SIP server, possibly one that then intercepts
   call requests or denies service.  A modified DHCP answer could also
   omit host names that translated to TLS-based SIP servers, thus
   facilitating intercept.

RFC2131[1]、RFC2543[2]、およびRFC3263[3]のセキュリティ問題は適用されます。 DHCPサーバから応答を変更するか、または敵が何とかそれ自身の応答を挿入するなら、SIPユーザエージェントが凶暴なSIPサーバ(ことによると次に、発呼要求を妨害するか、またはサービスを否定するもの)に連絡するように導かれるかもしれません。 また、変更されたDHCP答えはTLSベースのSIPサーバに翻訳された、その結果、インタセプトを容易にしたホスト名を省略するかもしれません。

Schulzrinne                 Standards Track                     [Page 4]

RFC 3361             DHCPv4 Option for SIP Servers           August 2002

Schulzrinne規格は2002年8月に一口サーバのためのRFC3361DHCPv4オプションを追跡します[4ページ]。

5.  IANA Considerations

5. IANA問題

   IANA has assigned a DHCP option number of 120 for the "SIP Servers
   DHCP Option" defined in this document.

IANAは本書では定義された「一口サーバDHCPオプション」のために120のDHCPオプション番号を割り当てました。

6.  Acknowledgements

6. 承認

   Ralph Droms, Robert Elz, Wenyu Jiang, Peter Koch, Gautam Nair, Thomas
   Narten, Erik Nordmark, Jonathan Rosenberg, Kundan Singh, Sven Ubik,
   Bernie Volz and Dean Willis provided useful feedback through the
   evolution of this document.

ラルフDroms、ロバートElz、Wenyu江、ピーター・コッホ、Gautamナイア、トーマスNarten、エリックNordmark、ジョナサン・ローゼンバーグ、Kundanシン、スベンUbik、バーニー・フォルツ、およびディーン・ウィリスはこのドキュメントの発展で役に立つフィードバックを提供しました。

7.  Bibliography

7. 図書目録

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

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

   [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
       Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
       Session Initiation Protocol", RFC 3261, June 2002.

[2] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

   [3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
       (SIP): Locating SIP Servers", RFC 3263, June 2002.

[3] ローゼンバーグ、J.、およびH.Schulzrinne、「セッション開始は(一口)について議定書の中で述べます」。 「一口サーバの場所を見つけます」、RFC3263、2002年6月。

   [4] Bradner, S., "Key words for use in RFCs to indicate requirement
       levels", BCP 14, RFC 2119, March 1997.

[4] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。

   [5] Alexander, S. and R. Droms, "DHCP options and BOOTP Vendor
       Extensions", RFC 2132, March 1997.

[5] アレクサンダー、S.、R.Droms、および「DHCPオプションとBOOTP Vendor Extensions」、RFC2132、3月1997日

   [6] Mockapetris, P., "Domain names - implementation and
       specification", STD 13, RFC 1035, November 1987.

[6]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日

   [7] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", Work in
       Progress.

[7] 「長いDHCPオプションをコード化し」て、レモン、T.、およびS.チェーシャー州は進行中で働いています。

Schulzrinne                 Standards Track                     [Page 5]

RFC 3361             DHCPv4 Option for SIP Servers           August 2002

Schulzrinne規格は2002年8月に一口サーバのためのRFC3361DHCPv4オプションを追跡します[5ページ]。

8. Author's Address

8. 作者のアドレス

   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027
   USA

コンピュータサイエンスColumbia University1214アムステルダムアベニューのヘニングSchulzrinne部、ニューヨーク、ニューヨーク10027の米国のM.C.0401

   EMail:  schulzrinne@cs.columbia.edu

メール: schulzrinne@cs.columbia.edu

Schulzrinne                 Standards Track                     [Page 6]

RFC 3361             DHCPv4 Option for SIP Servers           August 2002

Schulzrinne規格は2002年8月に一口サーバのためのRFC3361DHCPv4オプションを追跡します[6ページ]。

9.  Full Copyright Statement

9. 完全な著作権宣言文

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

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

Schulzrinne                 Standards Track                     [Page 7]

Schulzrinne標準化過程[7ページ]