Network Working Group S. Hanna
Requests for Comments: 2730 Sun Microsystems, Inc.
Category: Standards Track B. Patel
Intel Corp.
M. Shah
Microsoft Corp.
December 1999
Multicast Address Dynamic Client Allocation Protocol (MADCAP)
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This document defines a protocol, Multicast Address Dynamic Client Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers.
この文書では、ホストがマルチキャストアドレス割り当てサーバからマルチキャストアドレスを要求することを可能にするプロトコル、マルチキャストアドレス動的クライアント割り当てプロトコル（MADCAP）を定義しています。
Multicast Address Dynamic Client Allocation Protocol (MADCAP) is a protocol that allows hosts to request multicast address allocation services from multicast address allocation servers. This protocol is part of the Multicast Address Allocation Architecture being defined by the IETF Multicast Address Allocation Working Group. However, it may be used separately from the rest of that architecture as appropriate.
マルチキャストアドレス動的クライアント割り当てプロトコル（MADCAP）は、ホストがマルチキャストアドレス割り当てサーバからマルチキャストアドレス割り当てサービスを要求することを可能にするプロトコルです。このプロトコルはIETFマルチキャストアドレスの割り当てワーキンググループによって定義されているマルチキャストアドレス配分アーキテクチャの一部です。しかし、それは必要に応じて、そのアーキテクチャの残りの部分とは別個に使用することができます。
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 [9].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[9]。
Constants used by this protocol are shown as [NAME-OF-CONSTANT], and summarized in Appendix B.
このプロトコルによって使用される定数は、[NAME-OF-CONSTANT]として示され、および付録Bに要約されています
This specification uses a number of terms that may not be familiar to the reader. This section defines some of these and refers to other documents for definitions of others.
本明細書は、読者によく知らないかもしれない多くの用語を使用します。このセクションでは、これらのいくつかを定義し、他の人の定義については、他の文書を参照します。
MADCAP client or client A host requesting multicast address allocation services via MADCAP.
MADCAPを経由して、マルチキャストアドレス割り当てサービスを要求MADCAPクライアントまたはクライアントのホスト。
MADCAP server or server A host providing multicast address allocation services via MADCAP.
MADCAPを経由して、マルチキャストアドレス割り当てサービスを提供MADCAPサーバまたはサーバのホスト。
Multicast IP Multicast, as defined in [11] and modified in [12].
マルチキャストIPマルチキャスト、[11]で定義されており、[12]に変更できます。
Multicast Address An IP multicast address or group address, as defined in [11] and [13]. An identifier for a group of nodes.
[11]及び[13]で定義されるように、IPマルチキャストアドレスやグループアドレスをアドレスマルチキャスト。ノードのグループのための識別子。
Multicast Scope A range of multicast addresses configured so that traffic sent to these addresses is limited to some subset of the internetwork. See [3] and [13].
マルチキャストスコープこれらのアドレスに送信されたトラフィックは、インターネットのいくつかのサブセットに制限されるように構成されたマルチキャストアドレスの範囲。 [3]及び[13]を参照。
Scope ID The lowest numbered address in a multicast scope. This definition applies only within this document.
スコープIDマルチキャストスコープで最も小さい番号のアドレス。この定義は、この文書の中に適用されます。
Scope Zone One multicast scope may have several instances, which are known as Scope Zones or zones, for short.
スコープゾーンの1つのマルチキャスト範囲が短いため、スコープゾーンまたはゾーンとして知られているいくつかのインスタンスを有することができます。
For instance, an organization may have multiple sites. Each site might have its own site-local Scope Zone, each of which would be an instance of the site-local Scope. However, a given interface on a given host would only ever be in at most one instance of a given scope. Messages sent by a host in a site-local Scope Zones to an address in the site-local Scope would be limited to the site-local Scope Zone containing the host.
たとえば、組織が複数のサイトを持つことができます。各サイトは、サイトローカルスコープのインスタンスになり、それぞれが、独自のサイトローカルスコープゾーンを持っているかもしれません。しかし、与えられたホスト上の指定したインタフェースは今まで指定されたスコープの最大1つのインスタンスになります。サイトローカルスコープ内のアドレスにサイトローカルスコープゾーンにホストによって送信されたメッセージは、ホストを含むサイトローカルスコープゾーンに制限されます。
Zone Name A human readable name for a Scope Zone. An ISO 10646 character string with an RFC 1766 [6] language tag. One zone may have several zone names, each in a different language. For instance, a zone for use within IBM's locations in Switzerland might have the names "IBM Suisse", "IBM Switzerland", "IBM Schweiz", and "IBM Svizzera" with language tags "fr", "en", "de", and "it".
ゾーン名スコープゾーンの人間が読める形式の名前。 RFC 1766 [6]言語タグとISO 10646の文字列。一つのゾーンは、異なる言語でそれぞれをいくつかのゾーン名を有することができます。例えば、スイスでのIBMの拠点内で使用するためのゾーンが名前を持っているかもしれない「IBMスイス」、「IBMスイス」、「IBMスイス」、および言語タグ「FR」と「IBM Svizzera」、「EN」、「ド」 、そして「それ」。
Multicast Scope List A list of multicast scope zones.
マルチキャストスコープの一覧マルチキャストスコープゾーンのリスト。
Since it can be difficult to determine which multicast scope zones are in effect, MADCAP clients can ask MADCAP servers to supply a Multicast Scope List listing all of the zones available to the client. For each scope zone, the list includes the range of multicast addresses for this scope, a maximum TTL or hop count to be used for this scope, and one or more zone names for this scope zone.
それはマルチキャストスコープゾーンが有効になっているかを判断するのは難しいことができますので、MADCAPクライアントは、クライアントが利用可能なすべてのゾーンを一覧マルチキャストスコープの一覧を供給するMADCAPサーバに依頼することができます。各スコープのゾーンについて、リストには、このスコープのマルチキャストアドレス、この範囲に使用される最大TTL又はホップカウント、およびこのスコープゾーンの一つ以上のゾーン名の範囲を含みます。
This definition applies only within this document.
この定義は、この文書の中に適用されます。
For multicast applications to be deployed everywhere, there is a need to define a protocol that any host may use to allocate multicast addresses. Here are the requirements for such a protocol.
マルチキャストアプリケーションがどこにでも展開するために、任意のホストがマルチキャストアドレスを割り当てるために使用することができ、プロトコルを定義する必要があります。ここではそのようなプロトコルのための要件があります。
Quick response: The host should be able to allocate a multicast address and begin to use it promptly.
クイックレスポンス：ホストがマルチキャストアドレスを割り当て、速やかに使用を開始することができるはずです。
Low network load: Hosts that are not allocating or deallocating multicast addresses at the present time should not need to send or receive any network traffic.
低ネットワーク負荷：現時点でのマルチキャストアドレスを割り当てるか、割り当て解除されていないホストは、任意のネットワークトラフィックを送信または受信する必要はありません。
Support for intermittently connected or power managed systems: Hosts should be able to be disconnected from the network, powered off, or otherwise inaccessible except during the brief period during which they are allocating a multicast address.
ホストはネットワークから切断することができなければならない、電源オフ、またはそうでなければアクセスできないそれらはマルチキャストアドレスを割り当てている間に短い期間中を除く：断続的に接続されるか、または電力管理システムのサポート。
Multicast address scopes: The protocol must be able to allocate both the administratively scoped and globally scoped multicast addresses.
マルチキャストアドレスのスコープは：プロトコルは、管理用スコープとグローバルスコープのマルチキャストアドレスの両方を割り当てることができなければなりません。
Efficient use of address space: The multicast address space is fairly small. The protocol should make efficient use of this scarce resource.
アドレス空間の効率的な使用：マルチキャストアドレス空間はかなり小さいです。プロトコルは、この希少資源を効率的に使用する必要があります。
Authentication: Because multicast addresses are scarce, it is important to protect against hoarding of these addresses. One way to do this is by authenticating clients. This is also a key prerequisite for establishing policies.
認証：マルチキャストアドレスが不足しているので、それはこれらのアドレスの買いだめから保護することが重要です。これを行う1つの方法は、クライアントを認証することです。また、これは、ポリシーを確立するための重要な前提条件です。
Policy neutral: Allocation policies (such as who can allocate addresses) should not be dictated by the protocol.
ポリシーニュートラル：（そのようなアドレスを割り当てることができる人など）の割り当てポリシーは、プロトコルによって決定されるべきではありません。
Conferencing support: When allocating an address for use in a conferencing environment, members of the conference should be able to modify a multicast address lease used for the conference.
会議のサポート：会議環境で使用するためのアドレスを割り当てるときは、会議のメンバーが会議のために使用するマルチキャストアドレスのリースを変更することができるはずです。
MADCAP was originally based on DHCP. There are still some similarities and it may be possible to share some code between a DHCP implementation and a MADCAP implementation. However, MADCAP is completely separate from DHCP, with no dependencies between the two and many significant differences.
MADCAPはもともとDHCPに基づいていました。そこにいくつかの類似点が残っていると、DHCPの実装とMADCAP実装の間にいくつかのコードを共有することも可能です。しかし、MADCAPは2と多くの重要な相違点の間には依存関係で、DHCPから完全に分離されています。
MADCAP is built on a client-server model, where hosts request address allocation services from address allocation servers. When a MADCAP client wishes to request a service, it unicasts or multicasts a message to one or more MADCAP servers, each of which optionally responds with a message unicast to the client.
MADCAPは、ホストがアドレス割り当てサーバからアドレス割り当てサービスを要求するクライアントサーバモデル、上に構築されています。 MADCAPクライアントがサービスを要求したい場合には、必要に応じてクライアントにメッセージをユニキャストで応答それぞれが一つ以上のMADCAPサーバにメッセージをユニキャストまたはマルチキャスト。
All messages are UDP datagrams. The UDP data contains a fixed length header and a variable length options field. Options are encoded in a type-length-value format with two octets type and value fields. The fixed fields are version, msgtype (message type), addrfamily (address family), and xid (transaction identifier).
すべてのメッセージはUDPデータグラムです。 UDPデータは、固定長のヘッダと可変長のオプションフィールドを含みます。オプションは、2つのオクテットのタイプおよび値フィールドを持つタイプレングス値の形式で符号化されます。固定フィールドは、バージョン、MSGTYPE（メッセージタイプ）、addrfamily（アドレス・ファミリー）、及びXID（トランザクション識別子）です。
Retransmission is handled by the client. If a client sends a message and does not receive a response, it may retransmit its request a few times using an exponential backoff. To avoid executing the same client request twice when a retransmitted request is received, servers cache responses for a short period of time and resend cached responses upon receiving retransmitted requests.
再送がクライアントによって処理されます。クライアントがメッセージを送信し、応答を受信しない場合、それは指数バックオフを使用して、その要求を数回再送信することができます。再送された要求が受信された二回同じクライアントの要求を実行しないようにするには、サーバーは、短時間の応答をキャッシュして再送要求を受信すると、キャッシュされた応答を再送信します。
Each request contains a msgtype, an xid, and a Lease Identifier option. Clients must ensure that this triple is probably unique across all MADCAP messages received by a MADCAP server over a period of [XID-REUSE-INTERVAL] (10 minutes). This allows the MADCAP server to use this triple as the key in its response cache.
各要求はMSGTYPE、XID、およびリース識別子オプションが含まれています。クライアントは、このトリプルは、おそらく[XID - REUSE - INTERVAL]（10分）の期間にわたってMADCAPサーバが受信したすべてのMADCAPメッセージ全体で一意であることを確認する必要があります。これはMADCAPサーバが応答キャッシュ内のキーとして、このトリプルを使用することができます。
Messages sent by servers include the xid included in the original request so that clients can match up responses with requests.
サーバによって送信されたメッセージは、クライアントが要求に応答を一致させることができるように、元の要求に含まxidが含まれています。
The msgtype field is a single octet that defines the "type" of a MADCAP message. Currently defined message types are listed in Table 2. They are: DISCOVER, OFFER, REQUEST, RENEW, ACK, NAK, RELEASE, and
MSGTYPEフィールドはMADCAPメッセージの「タイプ」を定義する単一のオクテットです。現在、定義されたメッセージの種類を表2に列挙されている彼らは、次のとおり、OFFER、REQUESTを発見RENEW、ACK、NAK、RELEASE、および
GETINFO. DISCOVER, REQUEST, RENEW, RELEASE, and GETINFO messages are only sent by a client. OFFER, ACK, and NAK messages are only sent by a server.
情報を取得。 DISCOVER、REQUEST、RENEW、RELEASE、およびGETINFOメッセージのみクライアントによって送信されます。 OFFER、ACK、およびNAKメッセージは、サーバのみによって送信されます。
The REQUEST, RENEW, and RELEASE messages are used to request, renew, or release a lease on one or more multicast addresses. A client unicasts one of these messages to a server and the server responds with an ACK or a NAK.
REQUESTは、RENEW、およびRELEASEメッセージは、要求更新、または1つのまたは複数のマルチキャストアドレスのリースを解放するために使用されています。クライアントは、サーバにこれらのメッセージの1をユニキャスト、サーバはACKまたはNAKで応答します。
The GETINFO message is used to request information, such as the multicast scope list, or to find MADCAP servers. A client may unicast an GETINFO message to a MADCAP server. However, it may not know the IP address of any MADCAP server. In that case, it will multicast an GETINFO message to a MADCAP Server Multicast Address and all servers that wish to respond will send a unicast ACK or NAK back to the client.
GETINFOメッセージは、マルチキャストスコープのリストなどの情報を要求する、またはMADCAPサーバを見つけるために使用されます。クライアントはMADCAPサーバーにGETINFOメッセージをユニキャストします。しかし、それはどんなMADCAPサーバーのIPアドレスを知らないかもしれません。その場合には、MADCAPサーバーのマルチキャストアドレスにGETINFOメッセージをマルチキャストし、対応するすべてのサーバーは、クライアントにユニキャストACKまたはNAKを送信します。
Each multicast scope has an associated MADCAP Server Multicast Address. This address has been reserved by the IANA as the address with a relative offset of -1 from the last address of a multicast scope. MADCAP clients use this address to find MADCAP servers.
各マルチキャストスコープは、関連するMADCAPサーバーのマルチキャストアドレスを持っています。このアドレスは、マルチキャストスコープの最後のアドレスから-1の相対オフセットを持つアドレスとしてIANAによって予約されています。 MADCAPクライアントはMADCAPサーバを見つけるために、このアドレスを使用します。
The DISCOVER message is a message used to discover MADCAP servers that can probably satisfy a REQUEST. DISCOVER messages are always multicast. Servers that can probably satisfy a REQUEST corresponding to the parameters supplied in the DISCOVER message temporarily reserve the addresses needed and send a unicast OFFER back to the client. The client selects a server with which to continue and sends a multicast REQUEST including the server's Server Identifier to the same multicast address used for the DISCOVER. The chosen server responds with an ACK or NAK and the other servers stop reserving the addresses they were temporarily holding.
DISCOVERメッセージは、おそらく要求を満たすことができMADCAPサーバーを検出するために使用されるメッセージです。 DISCOVERメッセージは常にマルチキャストです。おそらくDISCOVERメッセージで指定されたパラメータに対応する要求を満たすことができるサーバは、一時的に必要なアドレスを予約し、クライアントへのユニキャストOFFERを送信します。クライアントが継続すると、サーバーを選択し、DISCOVERに使用したのと同じマルチキャストアドレスへのサーバーのサーバー識別子を含むマルチキャスト要求を送信します。選択したサーバーは、ACKまたはNAKで応答し、他のサーバーは、彼らが一時的に保持されたアドレスを予約止めます。
For detailed descriptions of typical protocol exchanges, consult Appendix A.
典型的なプロトコル交換の詳細な説明については、付録Aを参照してください
MADCAP is a mechanism rather than a policy. MADCAP allows local system administrators to exercise control over configuration parameters where desired. For example, MADCAP servers may be configured to limit the number of multicast addresses allocated to a single client. Properly enforcing such a limit requires cryptographic security, as described in the Security Consideration section.
MADCAPはメカニズムではなく、政策です。 MADCAPは、ローカルシステム管理者が所望の設定パラメータの制御を行使することを可能にします。例えば、MADCAPサーバは、単一のクライアントに割り当てられたマルチキャストアドレスの数を制限するように構成されてもよいです。セキュリティの考慮事項のセクションで説明したように適切な制限を強制することは、暗号のセキュリティが必要です。
MADCAP requests from a single host may be sent on behalf of different applications with different needs and requirements. MADCAP servers MUST NOT assume that because one request from a MADCAP client supports a particular optional feature (like Retry After), future requests from that client will also support that optional feature.
単一のホストからのMADCAP要求が異なるニーズや要件の異なるアプリケーションの代わりに送信することができます。 MADCAPサーバは、MADCAPクライアントからの要求が1（後に再試行のような）特定のオプション機能をサポートしているため、そのクライアントからの将来の要求にもそのオプション機能をサポートすると仮定してはいけません。
The MADCAP protocol is a client-server protocol. In general, the client unicasts or multicasts a message to one or more servers, which optionally respond with messages unicast to the client.
MADCAPプロトコルは、クライアント・サーバ・プロトコルです。一般的には、クライアントのユニキャストまたはマルチキャスト、必要に応じてクライアントにメッセージをユニキャストで応答の1つまたは複数のサーバーへのメッセージ、。
A reserved port number dedicated for MADCAP is used on the server (port number 2535, as assigned by IANA). Any port number may be used on client machines. When a MADCAP server sends a message to a MADCAP client, it MUST use a destination port number that matches the source port number provided by the client in the message that caused the server to send its message.
（IANAによって割り当てられ、ポート番号2535）MADCAP専用の予約されたポート番号は、サーバ上で使用されています。任意のポート番号は、クライアントマシン上で使用することができます。 MADCAPサーバーがMADCAPクライアントにメッセージを送信するときは、サーバーはそのメッセージを送信するために発生したメッセージには、クライアントによって提供されたソースポート番号と一致する宛先ポート番号を使用しなければなりません。
The next few sections describe the MADCAP message format and message types. A full list of MADCAP options is provided in section 3.
次のいくつかのセクションでは、MADCAPメッセージ形式とメッセージタイプについて説明します。 MADCAPオプションの完全なリストは、セクション3に設けられています。
Figure 1 gives the format of a MADCAP message and Table 1 describes each of the fields in the MADCAP message. The numbers in parentheses indicate the size of each field in octets. The names for the fields given in the figure will be used throughout this document to refer to the fields in MADCAP messages.
図1は、MADCAPメッセージのフォーマットを与え、表1は、MADCAPメッセージの各フィールドを記述する。括弧内の数字はオクテット内の各フィールドの大きさを示しています。図に与えられたフィールドの名前はMADCAPメッセージ内のフィールドを参照するために、この文書全体で使用されます。
All multi-octet quantities are in network byte-order.
すべてのマルチオクテット量は、ネットワークバイト順です。
Any message whose UDP data is too short to hold this format (at least 12 bytes) MUST be ignored.
そのUDPデータ任意のメッセージを無視しなければなりません。この形式（少なくとも12バイト）を保持するには短すぎます。
+-+-+-+-+-+-+-+-+
| version (1) |
+---------------+
| msgtype (1) |
+---------------+
| addrfamily |
| (2) |
+---------------+
| |
| xid (4) |
| |
| |
+---------------+
| |
| options |
| (variable) |
| ... |
+---------------+
Figure 1: Format of a MADCAP message
図1：MADCAPメッセージのフォーマット
FIELD OCTETS DESCRIPTION
----- ------ -----------
version 1 Protocol version number (zero for this specification) msgtype 1 Message type (DISCOVER, GETINFO, etc.) addrfamily 2 Address family (IPv4, IPv6, etc.) xid 4 Transaction ID options var Options field
バージョン1プロトコルバージョン番号（本明細書ではゼロ）（等DISCOVER、GETINFO）MSGTYPE 1つのメッセージタイプ（等のIPv4、IPv6の、）addrfamily 2つのアドレスファミリーXID 4つのトランザクションIDオプションVARオプションフィールド
Table 1: Description of fields in a MADCAP message
表1：MADCAPメッセージ内のフィールドの説明
The version field must always be zero for this version of the protocol. Any messages that include other values in this field MUST be ignored.
バージョンフィールドは、常にプロトコルのこのバージョンのためにゼロでなければなりません。この分野では他の値を含む任意のメッセージは無視しなければなりません。
The msgtype field defines the "type" of the MADCAP message.
MSGTYPEフィールドはMADCAPメッセージの「タイプ」を定義します。
For more information about this field, see section 2.2.
このフィールドの詳細については、セクション2.2を参照してください。
The addrfamily field defines the default address family (such as IPv4 or IPv6) for this MADCAP message, using the address family numbers defined in by the IANA (including those defined in [10]). Unless otherwise specified, all addresses included in the message will be from this family.
addrfamilyフィールドは、（[10]で定義されたものを含む）IANAによってで定義されたアドレスファミリー番号を使用して、このMADCAPメッセージの（IPv4やIPv6などの）デフォルトのアドレスファミリを定義します。特に指定しない限り、メッセージに含まれるすべてのアドレスは、この家族からになります。
The xid field is a transaction identifier. This number MUST be chosen by the client so that the combination of xid, msgtype, and Lease Identifier is unique across all MADCAP messages received by a MADCAP server over a period of [XID-REUSE-INTERVAL] (10 minutes).
XIDフィールドは、トランザクション識別子です。 XID、MSGTYPE、及びリース識別子の組み合わせが[XID-REUSE間隔（10分）の期間にわたってMADCAPサーバによって受信されたすべてのMADCAPメッセージ全体で一意であるように、この数は、クライアントによって選択されなければなりません。
The xid field is used by the client and server to associate messages and responses between a client and a server. Before a client sends a message, it chooses a number to use as an xid. The technique used to choose an xid is implementation-dependent, but whatever technique is used MUST make it unlikely that the same combination of xid, msgtype, and Lease Identifier will be used for two different messages within [XID-REUSE-INTERVAL] (even across multiple clients which do not communicate among themselves). This allows enough time for the message to be dropped from all server response caches (as described in the next few paragraphs) and for any network delays to be accomodated.
XIDフィールドは、クライアントとサーバー間のメッセージと応答を関連付けるために、クライアントとサーバによって使用されます。クライアントがメッセージを送信する前に、それはXIDとして使用する番号を選択します。 XIDを選択するために使用される技術は、実装依存であるが、どのような技術が使用されている、それはそうXID、MSGTYPE、およびリース識別子の同じ組み合わせが[XID-REUSE - INTERVAL]内の二つの異なるメッセージに使用されることを確認しなければならない（でも相互に通信していない複数のクライアント間で）。これは、すべてのサーバ応答キャッシュから（次のいくつかの段落に記載したように）とaccomodatedする任意のネットワーク遅延のためにドロップされるべきメッセージのための十分な時間を可能にします。
The RECOMMENDED technique for choosing an xid is to choose a random four octet number as the first xid in a session and increment this value each time a new xid is needed. The random number chosen need not be cryptographically random. The random number may be chosen via any suitable technique, such as the one described in section A.6 of RFC 1889 [14].
XIDを選択するための推奨手法は、セッションの最初のXIDようなランダム4つのオクテット番号を選択し、この値に新しいXIDが必要とされるたびにインクリメントすることです。選ばれた乱数は、暗号ランダムである必要はありません。乱数は、RFC 1889 [14]のセクションA.6に記載されるように、任意の適切な技術を介して選択することができます。
When a server responds to a client message, it MUST use the same xid value in the response that the client used in the request. This allows the client to associate responses with the message that they are responding to.
サーバがクライアントのメッセージに応答すると、それは、クライアントが要求で使用されることに応じて、同じxid値を使用しなければなりません。これにより、クライアントは、彼らがに応答しているメッセージで応答を関連付けることができます。
When retransmitting messages (as described in section 2.3), the client MUST retransmit them without changing them, thereby using the same xid and and Lease Identifier.
（セクション2.3で説明したように）メッセージを再送する場合、クライアントは、それによって同じXIDとし、リース識別子を用いて、それらを変更することなく、それらを再送しなければなりません。
If a server receives a message with the same xid, msgtype, and Lease Identifier as one received within [RESPONSE-CACHE-INTERVAL], it MUST treat this message as a retransmission of the previously received one and retransmit the response, if any. After [RESPONSE-CACHE-INTERVAL], the server may forget about the previously received message and treat any retransmissions of this message as if they were new messages. Of course, a server need not cache a message if it ends up ignoring that message. However, performance gains may be achieved by doing so.
サーバは一つの[RESPONSE-CACHE-INTERVAL]内に受信同じXID、MSGTYPE、及びリース識別子を持つメッセージを受信した場合、それが以前に受信された1つの再送信として、このメッセージを処理しなければならないし、もしあれば、応答を再送信します。 [RESPONSE-CACHE-INTERVAL]の後、サーバは、以前に受信したメッセージを忘れると、彼らが新しいメッセージであるかのように、このメッセージの再送を扱うことがあります。もちろん、サーバーはそのメッセージを無視してまで終了した場合、メッセージをキャッシュする必要はありません。しかし、パフォーマンスの向上は、そうすることによって達成することができます。
This avoids retransmissions causing multiple allocations, since requests are not idempotent. An appropriate value for [RESPONSE-CACHE-INTERVAL] would be sixty seconds, but it may have any value from zero seconds to 300 seconds (five minutes) and may be adjusted dynamically according to resource constraints on the server. However, using a value less than sixty seconds is NOT RECOMMENDED because this is the normal client retransmission period.
リクエストは冪等ではありませんので、これは、複数の割り当てを引き起こして再送信を回避することができます。 [RESPONSE-CACHE-INTERVAL]の適切な値は、60秒であろうが、それは300秒（5分）に0秒から任意の値を有していてもよいし、サーバ上のリソースの制約に応じて動的に調整されてもよいです。これは、通常のクライアントの再送信期間であるため、しかし、60秒未満の値を使用することはお勧めしません。
The options field consists of a list of tagged parameters that are called "options". All options consist of a two octet option code and a two octet option length, followed by the number of octets specified by the option length. In the case of some options, the length field is a constant but must still be specified.
オプションフィールドには、「オプション」と呼ばれているタグ付けされたパラメータのリストで構成されています。すべてのオプションは、オプションの長さで指定されたオクテットの数に続く、2つのオクテットのオプションコードと2つのオクテットオプションの長さで構成されています。いくつかのオプションの場合は、長さフィールドは一定であるが、まだ指定しなければなりません。
The option field MUST contain a sequence of options with the last one being the End option (option code 0). Any message whose options field does not conform to this syntax MUST be ignored.
オプションフィールドは、最後の1が終了オプション（オプションコード0）であることとオプションの配列を含有しなければなりません。この構文に準拠していないそのオプションフィールドの任意のメッセージは無視しなければなりません。
Any MADCAP client or server sending a MADCAP message MAY include any of the options listed in section 3, subject to the restrictions in Table 5 and elsewhere in this document. They MAY also include other MADCAP options that are defined in the future. A MADCAP client or server MUST NOT include more than one option with the same option type in one MADCAP message.
MADCAPメッセージを送信する任意のMADCAPクライアントまたはサーバは、表5の制限の対象と他の場所でこのドキュメントのセクション3に記載されているオプションのいずれかを含むことができます。彼らはまた、将来的に定義されている他のMADCAPオプションを含むかもしれません。 MADCAPクライアントまたはサーバが1つのMADCAPメッセージに同じオプションタイプを持つ複数のオプションを含んではいけません。
All MADCAP clients and servers MUST recognize all options listed in this document and behave in accordance with this document when receiving and processing any of these options. Any unrecognized options MUST be ignored and the rest of the message processed as if the unknown options were not present. If a MADCAP server receives a message that does not conform to the requirements of this document (for instance, not including all required options), an Invalid Request error MUST be generated and processed in the manner described in section 2.6. If a MADCAP client receives a message that does not conform to the requirements of this document, it MUST ignore the message.
すべてのMADCAPクライアントとサーバは、この文書に記載されているすべてのオプションを認識し、これらのオプションのいずれかを受信して処理するときに、この文書に従って振る舞う必要があります。認識されないオプションは無視されなければならない、未知のオプションが存在しないかのようにメッセージの残りの部分が処理されます。 MADCAPサーバが（例えば、必要なすべてのオプションを含めていない）は、この文書の要件に適合しないメッセージを受信した場合、無効なリクエストエラーが生成され、セクション2.6に記載された方法で処理されなければなりません。 MADCAPクライアントは、この文書の要求事項に適合していないメッセージを受信した場合、それはメッセージを無視しなければなりません。
The order of options within a message has no significance and any order MUST be supported in an equivalent manner, with the exception that the End option must occur once per message, as the last option in the option field.
メッセージ内のオプションの順序に意味はありませんし、任意の順序は、エンド・オプションがオプションフィールドの最後のオプションとして、メッセージごとに一度発生しなければならないことを除いて、同等の方法でサポートしなければなりません。
New MADCAP option codes may only be defined by IETF Consensus, as described in section 5.
セクション5に記載されているように新しいMADCAPオプションコードのみ、IETF合意によって定義されてもよいです。
The msgtype field defines the "type" of a MADCAP message. Legal values for this field are:
MSGTYPEフィールドはMADCAPメッセージの「タイプ」を定義します。このフィールドの有効な値は以下のとおりです。
Value Message Type
----- ------------
1 DISCOVER
2 OFFER
3 REQUEST
4 RENEW
5 ACK
6 NAK
7 RELEASE
8 GETINFO
Table 2: MADCAP message types
表2：MADCAPメッセージタイプ
Throughout this document, MADCAP messages will be referred to by the type of the message; e.g., a MADCAP message with a message type of 8 will be referred to as an GETINFO message.
本明細書を通して、MADCAPメッセージは、メッセージのタイプによって参照されます。例えば、8のメッセージ・タイプのMADCAPメッセージはGETINFOメッセージと呼ぶことにします。
Here are descriptions of the MADCAP message types. Table 5, which appears at the beginning of section 3, summarizes which options are allowed with each message type.
ここではMADCAPメッセージタイプの記述があります。セクション3の先頭に表示され、表5には、各メッセージタイプで許可されているオプションをまとめたものです。
MADCAP clients and servers MUST handle all MADCAP message types defined in this document in a manner consistent with this document.
MADCAPクライアントとサーバは、この文書と一致する方法で、この文書で定義されたすべてのMADCAPメッセージタイプを処理する必要があります。
If a MADCAP server receives a message whose message type it does not recognize, an Invalid Request error MUST be generated and processed in the manner described in section 2.6. If a MADCAP client receives a message whose message type it does not recognize, it MUST ignore the message.
MADCAPサーバは、そのメッセージタイプが認識されないメッセージを受信した場合、無効なリクエストエラーが生成され、セクション2.6に記載された方法で処理されなければなりません。 MADCAPクライアントはそのメッセージタイプが認識できないメッセージを受信した場合、それはメッセージを無視しなければなりません。
Note, however, that under some circumstances this document requires or suggests that clients or servers ignore messages with certain message types even though they may be recognized. For instance, clients that do not send DISCOVER messages SHOULD ignore OFFER messages. Also, secure servers SHOULD ignore DISCOVER messages and all servers SHOULD ignore DISCOVER messages that they cannot satisfy.
いくつかの状況下では、この文書が必要ですかクライアントまたはサーバは、彼らが認識されていても、特定のメッセージタイプでメッセージを無視することを示唆していること、しかし、注意してください。例えば、DISCOVERメッセージを送信しないクライアントは、OFFERメッセージを無視すべきです。また、安全なサーバーがDISCOVERメッセージを無視すべきであり、すべてのサーバーは、彼らが満足することはできませんDISCOVERメッセージを無視すべきです。
New MADCAP message types may only be defined by IETF Consensus, as described in section 5.
セクション5に記載されているように、新しいMADCAPメッセージタイプのみ、IETF合意によって定義されてもよいです。
The GETINFO message is used by a MADCAP client that wants to acquire configuration parameters, especially a multicast scope list. This message also allows a client to determine which servers are likely to be able to handle future requests.
GETINFOメッセージは、設定パラメータ、特にマルチキャストスコープの一覧を取得したいMADCAPクライアントによって使用されます。このメッセージは、将来の要求を処理することができそうであるサーバを決定するためにクライアントを可能にします。
The MADCAP client sends out an GETINFO message. The message may be unicast to a particular MADCAP server or multicast to a MADCAP Server Multicast Address. For more details about the MADCAP Server Multicast Address, see section 2.10.
MADCAPクライアントがGETINFOメッセージを送信します。メッセージはMADCAPサーバマルチキャストアドレスに特定のMADCAPサーバまたはマルチキャストへユニキャストしてもよいです。 MADCAPサーバーのマルチキャストアドレスの詳細については、セクション2.10を参照してください。
If a server receives an GETINFO message and it can process the request successfully, it MUST unicast an ACK message to the client. All GETINFO messages MUST include an Option Request List option. The server SHOULD try to include the specified options in its response, but is not required to do so (especially if it does not recognize them).
サーバがGETINFOメッセージを受信し、それが成功した要求を処理できる場合は、それがクライアントにACKメッセージをユニキャストしなければなりません。すべてのGETINFOメッセージは、オプション要求リストのオプションを含まなければなりません。サーバは、その応答で指定されたオプションが含まれるようにしようとする必要がありますが、（それはそれを認識しない場合は特に）、そうする必要はありません。
If a server receives an GETINFO message and it does not process the request successfully, it MUST generate and process an error in the manner described in section 2.6.
サーバがGETINFOメッセージを受信し、要求を正常に処理しない場合は、セクション2.6に記載の方法でエラーを生成して処理しなければなりません。
If a client sends an GETINFO message and does not receive any ACK messages in response, it SHOULD resend its GETINFO message, as described in section 2.3.
クライアントがGETINFOメッセージを送信し、応答における任意のACKメッセージを受信しない場合はセクション2.3で説明したように、それは、そのGETINFOメッセージを再送信する必要があります。
When a MADCAP client sends an GETINFO message, it MAY include the Requested Language option, which specifies which language the client would prefer for the zone names in the Multicast Scope List. The proper way to handle this tag with respect to zone names is discussed in the definition of the Multicast Scope List option.
MADCAPクライアントがGETINFOメッセージを送信すると、それは、クライアントがマルチキャストスコープ一覧でゾーン名のために希望する言語を指定するリクエストされた言語オプションを含むことができます。ゾーン名に対するこのタグを処理するための適切な方法は、マルチキャストスコープの一覧オプションの定義で説明されています。
The DISCOVER message is a multicast message sent by a MADCAP client that wants to discover MADCAP servers that can probably satisfy a REQUEST.
DISCOVERメッセージは、おそらく要求を満たすことができMADCAPサーバーを検出しようとMADCAPクライアントによって送信されたマルチキャストメッセージです。
MADCAP clients are not required to use the DISCOVER message. They MAY employ other methods to find MADCAP servers, such as sending a multicast GETINFO message, caching an IP address that worked in the past or being configured with an IP address. Using the DISCOVER message has the particular advantage that it allows clients to receive responses from all servers that can satisfy the request.
MADCAPクライアントはDISCOVERメッセージを使用する必要はありません。彼らは、このような、マルチキャストGETINFOメッセージを送信し、過去に働いていたIPアドレスをキャッシュするか、IPアドレスで構成されているようMADCAPサーバーを見つけるために、他の方法を採用することができます。 DISCOVERメッセージを使用すると、それは、クライアントが要求を満たすことができ、すべてのサーバーからの応答を受け取ることを可能にする特別な利点があります。
The MADCAP client begins by sending a multicast DISCOVER message to a MADCAP Server Multicast Address. Any servers that wish to assist the client respond by sending a unicast OFFER message to the client. If a server can only process the request with a shorter lease time or later start time than the client requested, it SHOULD send an OFFER message with the lease time or start time that it can offer. However, it MUST NOT offer a lease time shorter than the minimum lease time specified by the client or a start time later than the maximum start time specified by the client.
MADCAPクライアントはMADCAPサーバーのマルチキャストアドレスにマルチキャストDISCOVERメッセージを送信することで始まります。クライアントへのユニキャストOFFERメッセージを送信することにより、クライアントの応答を支援したい任意のサーバー。サーバが唯一の短いリース時間で要求を処理以降のクライアントが要求したよりも時間を開始することができた場合は、リース期間にOFFERメッセージを送信したり、それが提供できることを時間を開始する必要があります。しかし、それはクライアント以降のクライアントによって指定された最大開始時刻より開始時刻で指定された最小リース時間より短いリース時間を提供してはいけません。
For more details about the MADCAP Server Multicast Address, see section 2.10.
MADCAPサーバーのマルチキャストアドレスの詳細については、セクション2.10を参照してください。
If a client sends a DISCOVER message and does not receive any OFFER messages in response, the client SHOULD retransmit its DISCOVER message, as described in section 2.3.
クライアントはDISCOVERメッセージを送信し、それに応じて任意のOFFERメッセージを受信しない場合はセクション2.3で説明したように、クライアントは、そのDISCOVERメッセージを再送すべきです。
If a client sends a DISCOVER message and receives one or more OFFER messages in response, it SHOULD select the server it wants to use (if any) and send a multicast REQUEST message identifying that server within [DISCOVER-DELAY] after receiving the first OFFER message. See section 2.2.4 for more information about the REQUEST message.
クライアントはDISCOVERメッセージを送信し、応答して1つのまたは複数のOFFERメッセージを受信した場合、それは使用します（もしあれば）と最初のオファーを受けた後、[DISCOVER - DELAY]内そのサーバーを特定するマルチキャスト要求メッセージを送信したいサーバーを選択する必要がありますメッセージ。 REQUESTメッセージの詳細については、セクション2.2.4を参照してください。
The mechanism used by the client in selecting the server it wants to use is implementation dependent. The client MAY choose the first acceptable response or it MAY wait some period of time (no more than [DISCOVER-DELAY]) and choose the best response received in that period of time (if the first response has a smaller lease time than requested, for instance).
それは使用したいサーバーを選択するには、クライアントが使用するメカニズムは、実装依存です。クライアントが最初の許容応答を選択したり、それが一定の時間を待つこと（を超えない[-DELAYを発見]）と最初の応答が要求よりも小さいリース時間を持っている場合（その期間に受けた最適な応答を選択し、例えば）。
The value of [DISCOVER-DELAY] is also implementation dependent, but the RECOMMENDED value is the current retransmit timer, as specified in section 2.3. Waiting too long (approaching [OFFER-HOLD]) may cause servers to drop the addresses they have reserved.
[DISCOVER-DELAY]の値は、実装に依存するが、セクション2.3で指定されるように推奨値は、現在の再送信タイマーです。あまりにも長い間待っている（近づい[OFFER-HOLD]）は、サーバは、彼らが予約したアドレスをドロップする可能性があります。
When a MADCAP client sends a DISCOVER message, it MAY include the Lease Time, Minimum Lease Time, Start Time, Maximum Start Time, Number of Addresses Requested, and List of Address Ranges options, describing the addresses it wants to receive. However, it need not include any of these options. If one of these options is not included, the server will provide the appropriate default (maximum available for Lease Time, no minimum for Minimum Lease Time, as soon as possible for Start Time, no maximum for Maximum Start Time, one for Number of Addresses Requested, and any addresses available for List of Address Ranges). The Multicast Scope option MUST be included in the DISCOVER message so that the server knows what scope should be used. The Current Time option MUST be included if the Start Time or Maximum Start Time options are included. The Lease Identifier option
MADCAPクライアントがDISCOVERメッセージを送信するときに、リース期間、最低のリース時間、開始時間、最大開始時間、要求されたアドレスの数を含むことができ、アドレスのリストは、それが受信したいアドレスを記述し、オプションの範囲。しかし、それは、これらのオプションのいずれかを含む必要はありません。これらのいずれかのオプションが含まれていない場合、サーバーは開始時間、最大開始時間のための最大値なし、アドレス数のための1のための適切なデフォルト（リース期間、最低のリース時間のためノー最小の最大利用可能、できるだけ早くを提供します要求された、およびアドレス範囲のリストに利用可能な任意のアドレス）。サーバはスコープを使用すべきかを知っているように、マルチキャストスコープオプションは、DISCOVERメッセージに含まれなければなりません。開始時間または最大開始時間のオプションが含まれている場合、現在の時間オプションが含まれなければなりません。リース識別子オプション
MUST always be included.
常に含まれなければなりません。
The OFFER message is a unicast message sent by a MADCAP server in response to a DISCOVER message that it can probably satisfy.
OFFERメッセージには、それはおそらく満たすことができるDISCOVERメッセージに応答してMADCAPサーバーによって送信されたユニキャストメッセージです。
A MADCAP server is never required to send an OFFER message in response to a DISCOVER message. For instance, it may not be able to satisfy the client's request or it may have been configured to respond only to certain types of DISCOVER messages or not to respond to DISCOVER messages at all.
MADCAPサーバーがDISCOVERメッセージに対応してOFFERメッセージを送信するために必要とされることはありません。例えば、クライアントの要求を満たすことができないかもしれませんか、すべてでメッセージを発見するために応答するだけDISCOVERメッセージかどうかの特定の種類に応答するように構成されている場合があります。
If a MADCAP server decides to send an OFFER message, it MUST include the Lease Time and Multicast Scope options, describing the addresses it is willing to provide. However, it need not include the List of Address Ranges option. If the List of Address Ranges Allocated option is not included, it is assumed that the server is willing to provide the number of addresses that the client requested. If the Start Time option is not included, it is assumed that the server is willing to provide the start time requested by the client (if any). The Current Time option MUST be included if the Start Time option is included.
MADCAPサーバーがOFFERメッセージを送信することを決定した場合、提供する意思があるアドレスを記述し、リース期間およびマルチキャストスコープオプションを含まなければなりません。しかし、それはオプションのアドレス範囲のリストを含む必要はありません。オプションに割り当てられたアドレス範囲のリストが含まれていない場合は、サーバは、クライアントが要求されたアドレスの数を提供する意思があることが想定されます。開始時間のオプションが含まれていない場合は、サーバがクライアント（もしあれば）によって要求された開始時間を提供する意思があることが想定されます。開始時間のオプションが含まれている場合、現在時刻のオプションが含まれなければなりません。
If a server can process the request with a shorter lease time or later start time than the client requested, it SHOULD send an OFFER message with the lease time or start time that it can offer. However, it MUST NOT offer a lease time shorter than the minimum lease time specified by the client or a start time later than the maximum start time specified by the client.
サーバが短いリース時間で要求を処理以降のクライアントが要求したよりも時間を開始することができた場合は、リース期間にOFFERメッセージを送信したり、それが提供できることを時間を開始する必要があります。しかし、それはクライアント以降のクライアントによって指定された最大開始時刻より開始時刻で指定された最小リース時間より短いリース時間を提供してはいけません。
If the server sends an OFFER message, it SHOULD attempt to hold enough addresses to complete the transaction. If it receives a multicast REQUEST message with the same Lease Identifier option as the DISCOVER message for which it is holding these addresses and a Server Identifier option that does not match its own, it SHOULD stop holding the addresses. The server SHOULD also stop holding the addresses after an appropriate delay [OFFER-HOLD] if the transaction is not completed. The value of this delay is implementation-specific, but a value of at least 60 seconds is RECOMMENDED.
サーバはOFFERメッセージを送信した場合は、トランザクションを完了するのに十分なアドレスを保持しようとすべきです。それは、これらのアドレスを保持しているためDISCOVERメッセージと同じリース識別子オプションと、独自に一致しないサーバ識別子オプションを持つマルチキャストREQUESTメッセージを受信した場合、それはアドレスを保持停止する必要があります。また、サーバは、トランザクションが完了しない場合、適切な遅延[OFFER-HOLD]後にアドレスを保持停止する必要があります。この遅延の値は、実装に固有であるが、少なくとも60秒の値が推奨されます。
As with all messages sent by the server, the xid field MUST match the xid field included in the client request to which this message is responding. The Lease Identifier option MUST be included, with the value matching the one included in the client request. The Server Identifier option MUST be included, with the value being the server's IP address. And the packet MUST NOT be retransmitted.
サーバーによって送信されたすべてのメッセージと同じように、XIDフィールドはXIDフィールドと一致する必要があります。このメッセージが応答しているために、クライアントのリクエストに含まれます。リース識別子オプションは、クライアントの要求に含まれる1つに一致する値が含まれなければなりません。サーバ識別子オプションは、値は、サーバーのIPアドレスであることを、含まれなければなりません。そして、パケットを再送してはなりません。
The REQUEST message is used by a MADCAP client that wants to allocate one or more multicast addresses. It is not used for renewing an existing lease. The RENEW message is used for that.
REQUESTメッセージは、1つまたは複数のマルチキャストアドレスを割り当てたいMADCAPクライアントによって使用されます。これは、既存のリースを更新するために使用されていません。 RENEWメッセージは、そのために使用されています。
If a REQUEST message is completing a transaction initiated by a DISCOVER message, the following procedure MUST be followed so that all MADCAP servers know which server was selected. The client MUST multicast a REQUEST message to the same MADCAP Server Multicast Address that the DISCOVER message was sent to. The same Lease Identifier used in the DISCOVER message MUST be used in the REQUEST message. Also, the Server Identifier option MUST be included, using the Server Identifier of the server selected.
REQUESTメッセージがDISCOVERメッセージによって開始されたトランザクションを完了している場合は、すべてのMADCAPサーバが選択されたサーバーを知っているように、次の手順に従わなければなりません。クライアントは、DISCOVERメッセージが送られた同じMADCAPサーバーのマルチキャストアドレスに要求メッセージをマルチキャストしなければなりません。 DISCOVERメッセージで使用したのと同じリース識別子は、要求メッセージで使用されなければなりません。また、サーバ識別子オプションは、選択したサーバーのサーバー識別子を使用して、含まれなければなりません。
If a REQUEST message is not completing a transaction initiated by a DISCOVER message, the REQUEST message MUST be unicast to the MADCAP server that the client wants to use. In this case, the Server Identifier option MAY be included, but need not be.
REQUESTメッセージがDISCOVERメッセージによって開始されたトランザクションを完了していない場合は、REQUESTメッセージは、クライアントが使用したいMADCAPサーバにユニキャストでなければなりません。この場合、サーバ識別子オプションを含めてもよいが、である必要はありません。
If the selected server can process the request successfully, it SHOULD unicast an ACK message to the client. Otherwise, it SHOULD generate and process an error in the manner described in section 2.6. If a server can process the request with a shorter lease time or later start time than the client requested, it SHOULD send an ACK message with the lease time or start time that it can offer. However, it MUST NOT offer a lease time shorter than the minimum lease time specified by the client or a start time later than the maximum start time specified by the client.
選択したサーバーが正常に要求を処理できる場合は、それがクライアントにACKメッセージをユニキャストすべきです。それ以外の場合は、セクション2.6に記載の方法でエラーを生成して処理しなければなりません。サーバが短いリース時間で要求を処理以降のクライアントが要求したよりも時間を開始することができた場合は、リース期間にACKメッセージを送信したり、それが提供できることを時間を開始する必要があります。しかし、それはクライアント以降のクライアントによって指定された最大開始時刻より開始時刻で指定された最小リース時間より短いリース時間を提供してはいけません。
When a MADCAP client sends a REQUEST message, it MAY include the Lease Time, Minimum Lease Time, Start Time, Maximum Start Time, Number of Addresses Requested, and List of Address Ranges options, describing the addresses it wants to receive. However, it need not include any of these options. If one of these options is not included, the server will provide the appropriate default (maximum available for Lease Time, no minimum for Minimum Lease Time, as soon as possible for Start Time, no maximum for Maximum Start Time, one for Number of Addresses Requested, and any addresses available for List of Address Ranges). The Multicast Scope option MUST be included in the REQUEST message so that the server knows what scope should be used. The Current Time option MUST be included if the Start Time or Maximum Start Time options are included.
MADCAPクライアントが要求メッセージを送信すると、それはリース期間、最低のリース時間、開始時間、最大開始時間、要求されたアドレスの数を含むことができ、アドレスのリストは、それが受信したいアドレスを記述し、オプションの範囲。しかし、それは、これらのオプションのいずれかを含む必要はありません。これらのいずれかのオプションが含まれていない場合、サーバーは開始時間、最大開始時間のための最大値なし、アドレス数のための1のための適切なデフォルト（リース期間、最低のリース時間のためノー最小の最大利用可能、できるだけ早くを提供します要求された、およびアドレス範囲のリストに利用可能な任意のアドレス）。サーバはスコープを使用すべきかを知っているように、マルチキャストスコープオプションは、要求メッセージに含まれなければなりません。開始時間または最大開始時間のオプションが含まれている場合、現在の時間オプションが含まれなければなりません。
If a client sends a REQUEST message and does not receive any ACK or NAK messages in response, the client SHOULD resend its REQUEST message, as described in section 2.3.
クライアントが要求メッセージを送信し、それに応じて任意のACKまたはNAKメッセージを受信しない場合はセクション2.3で説明したように、クライアントは、そのREQUESTメッセージを再送する必要があります。
If the server responds with a NAK or fails to respond within a reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the client MAY try to find another server by sending a DISCOVER message with another xid or sending a REQUEST message with another xid to another server. The RECOMMENDED value for [NO-RESPONSE-DELAY] is 60 seconds.
サーバが[NO-RESPONSE-DELAY] NAKで応答したり、妥当な（実装依存）内に応答しなかった遅延した場合、クライアントは別のxidでDISCOVERメッセージを送信したりとREQUESTメッセージを送信することにより、別のサーバーを見つけることを試みることができます別のサーバーへの別のxid。 [NO-RESPONSE-DELAY]の推奨値は60秒です。
The ACK message is used by a MADCAP server to respond affirmatively to an GETINFO, REQUEST, or RELEASE message. The server unicasts the ACK message to the client from which it received the message to which it is responding.
ACKメッセージはGETINFO、REQUEST、またはRELEASEメッセージに肯定応答するMADCAPサーバによって使用されます。サーバーは、それが応答されたメッセージを受信したクライアントへのACKメッセージをユニキャストします。
The set of options included with an ACK message differs, depending on what sort of message it is responding to.
ACKメッセージに含まれているオプションのセットは、それがに応答しているメッセージの種類をによって異なります。
If the ACK message is responding to an GETINFO message, it SHOULD include any options requested by the client using the Option Request List option.
ACKメッセージはGETINFOメッセージに応答している場合は、オプション要求リストのオプションを使用して、クライアントから要求されたすべてのオプションを含むべきです。
If the ACK message is responding to a REQUEST message, it MUST include Lease Time, Multicast Scope, and List of Address Ranges options. It MAY include a Start Time option. If a Start Time option is included, a Current Time option MUST also be included. If no Start Time option is included, the lease is assumed to start immediately.
ACKメッセージが要求メッセージに応答している場合は、リース期間、マルチキャストスコープを含まなければならない、とアドレスの一覧は、オプションの範囲。これは、開始時間のオプションを含むかもしれません。開始時間のオプションが含まれている場合は、現在のTimeオプションも含まれなければなりません。何の開始時間オプションが含まれていない場合は、リースがすぐに開始すると想定されます。
If the ACK message is responding to a RENEW message, it MUST include Lease Time, Multicast Scope, and List of Address Ranges options. It MAY include a Start Time option. If a Start Time option is included, a Current Time option MUST also be included. If no Start Time option is included, the lease is assumed to start immediately.
ACKメッセージがRENEWメッセージに応答している場合は、リース期間、マルチキャストスコープを含まなければならない、とアドレスの一覧は、オプションの範囲。これは、開始時間のオプションを含むかもしれません。開始時間のオプションが含まれている場合は、現在のTimeオプションも含まれなければなりません。何の開始時間オプションが含まれていない場合は、リースがすぐに開始すると想定されます。
If the ACK message is responding to a RELEASE message, it MUST only include Server Identifier and Lease Identifier options.
ACKメッセージがRELEASEメッセージに応答している場合は、それだけでサーバー識別子とリース識別子オプションを含まなければなりません。
As with all messages sent by the server, the xid field MUST match the xid field included in the client request to which this message is responding. The Lease Identifier option MUST be included, with the value matching the one included in the client request. The Server Identifier option MUST be included, with the value being the server's IP address. And the packet MUST NOT be retransmitted.
サーバーによって送信されたすべてのメッセージと同じように、XIDフィールドはXIDフィールドと一致する必要があります。このメッセージが応答しているために、クライアントのリクエストに含まれます。リース識別子オプションは、クライアントの要求に含まれる1つに一致する値が含まれなければなりません。サーバ識別子オプションは、値は、サーバーのIPアドレスであることを、含まれなければなりません。そして、パケットを再送してはなりません。
The NAK message is used by a MADCAP server to respond negatively to a message. The server unicasts the NAK message to the client from which it received the message to which it is responding.
NAKメッセージはメッセージに否定応答するMADCAPサーバによって使用されます。サーバーは、それが応答されたメッセージを受信し、そこからクライアントにNAKメッセージをユニキャストします。
As with all messages sent by the server, the xid field MUST match the xid field included in the client request to which this message is responding. The Lease Identifier option MUST be included, with the value matching the one included in the client request. The Server Identifier option MUST be included, with the value being the server's IP address. The Error option MUST be included with an error code indicating what went wrong. And the packet MUST NOT be retransmitted.
サーバーによって送信されたすべてのメッセージと同じように、XIDフィールドはXIDフィールドと一致する必要があります。このメッセージが応答しているために、クライアントのリクエストに含まれます。リース識別子オプションは、クライアントの要求に含まれる1つに一致する値が含まれなければなりません。サーバ識別子オプションは、値は、サーバーのIPアドレスであることを、含まれなければなりません。 Errorオプションは、何が悪かったのかを示すエラーコードに含まれなければなりません。そして、パケットを再送してはなりません。
The RENEW message is used by a MADCAP client that wants to renew a multicast address lease, changing the lease time or start time.
RENEWメッセージは、マルチキャストアドレスのリースを更新リース時間を変更したり、時間を開始したいMADCAPクライアントによって使用されます。
The client unicasts the RENEW message to a MADCAP server. If the server can process the request successfully, it SHOULD unicast an ACK message to the client. Otherwise, it MUST generate and process an error in the manner described in section 2.6.
クライアントはMADCAPサーバーにRENEWメッセージをユニキャストします。サーバは要求を正常に処理できた場合、それはクライアントにACKメッセージをユニキャストすべきです。それ以外の場合は、セクション2.6に記載の方法でエラーを生成して処理しなければなりません。
The lease to be renewed is whichever one was allocated with a Lease Identifier option matching the one provided in the RENEW message.
更新されるリースは、一つがRENEWメッセージにおいて提供される一つのマッチングリース識別子オプションで割り当てられた方です。
When a MADCAP client sends a RENEW message, it MAY include the Lease Time, Minimum Lease Time, Start Time, and Maximum Start Time options, describing the new lease it wants to receive. However, it need not include any of these options. If one of these options is not included, the server will provide the appropriate default (maximum available for Lease Time, no minimum for Minimum Lease Time, as soon as possible for Start Time, and no maximum for Maximum Start Time). The Current Time option MUST be included if the Start Time or Maximum Start Time options are included.
MADCAPクライアントがRENEWメッセージを送信すると、それが受信したい新しいリースを記述し、リース期間、最低のリース時間、開始時間、および最大開始時間のオプションを含むかもしれません。しかし、それは、これらのオプションのいずれかを含む必要はありません。これらのいずれかのオプションが含まれていない場合は、サーバが適切なデフォルト（開始時間の最大リース期間、最低のリース時間のためノー最小に利用可能な、できるだけ早く、かつ最大開始時間について上限なし）を提供します。開始時間または最大開始時間のオプションが含まれている場合、現在の時間オプションが含まれなければなりません。
If a client sends a RENEW message and does not receive any ACK or NAK messages in response, the client SHOULD resend its RENEW message, as described in section 2.3.
クライアントがRENEWメッセージを送信し、それに応じて任意のACKまたはNAKメッセージを受信しない場合はセクション2.3で説明したように、クライアントは、そのRENEWメッセージを再送信する必要があります。
If the server responds with a NAK or fails to respond within a reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the client MAY send a RENEW message with another xid to another server, provided that the Server Mobility feature was used in the original REQUEST message and that this feature is required for the subsequent RENEW message sent to another server. For more information about the Server Mobility feature, see section 2.13.1. The RECOMMENDED value for [NO-RESPONSE-DELAY] is 60 seconds.
サーバが[NO-RESPONSE-DELAY] NAKで応答したり、妥当な（実装依存）内に応答しなかった遅延した場合、クライアントはサーバーのモビリティ機能を使用したことを提供し、別のサーバーに別のxidのRENEWメッセージを送信することができます元の要求メッセージ内とすることを、この機能は別のサーバに送信され、後続のRENEWメッセージに必要とされます。サーバーのモビリティ機能の詳細については、セクション2.13.1を参照してください。 [NO-RESPONSE-DELAY]の推奨値は60秒です。
The RELEASE message is used by a MADCAP client that wants to deallocate one or more multicast addresses before their lease expires.
RELEASEメッセージは、そのリース期限が切れる前に、1つまたは複数のマルチキャストアドレスの割り当てを解除したいMADCAPクライアントによって使用されます。
The client unicasts the RELEASE message to the MADCAP server from which it allocated the addresses. If the selected server can process the request successfully, it MUST unicast an ACK message to the client. Otherwise, it MUST generate and process an error in the manner described in section 2.6.
クライアントは、それがアドレスを割り当てられ、そこからMADCAPサーバにRELEASEメッセージをユニキャストします。選択したサーバーが正常に要求を処理できる場合は、それがクライアントにACKメッセージをユニキャストしなければなりません。それ以外の場合は、セクション2.6に記載の方法でエラーを生成して処理しなければなりません。
The lease to be released is whichever one was allocated with a Lease Identifier option matching the one provided in the RELEASE message. It is not possible to release only part of the addresses in a single lease.
解放されるリースは、一つがRELEASEメッセージ内に設けられたものを一致リース識別子オプションで割り当てられた方です。単一のリースのアドレスの一部のみをリリースすることはできません。
If a client sends a RELEASE message and does not receive any ACK or NAK messages in response, the client SHOULD resend its RELEASE message, as described in section 2.3.
クライアントがRELEASEメッセージを送信し、それに応じて任意のACKまたはNAKメッセージを受信しない場合はセクション2.3で説明したように、クライアントは、そのRELEASEメッセージを再送する必要があります。
If the server responds with a NAK or fails to respond within a reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the client MAY send a RELEASE message with another xid to another server, provided that the Server Mobility feature was used in the original REQUEST message and that this feature is required for the subsequent RELEASE message sent to another server. For more information about the Server Mobility feature, see section 2.13.1. The RECOMMENDED value for [NO-RESPONSE-DELAY] is 60 seconds.
サーバがNAKで応答したり、妥当な（実装依存）内に応答しなかった場合の遅延[NO-RESPONSE-DELAY]、クライアントは別のサーバーに別のxidのRELEASEメッセージを送信することができる、サーバーのモビリティ機能を使用したことを提供元の要求メッセージ内とすることを、この機能は別のサーバに送信された後続のRELEASEメッセージに必要とされます。サーバーのモビリティ機能の詳細については、セクション2.13.1を参照してください。 [NO-RESPONSE-DELAY]の推奨値は60秒です。
MADCAP clients are responsible for all message retransmission. The client MUST adopt a retransmission strategy that incorporates an exponential backoff algorithm to determine the delay between retransmissions. The delay between retransmissions SHOULD be chosen to allow sufficient time for replies from the server to be delivered based on the characteristics of the internetwork between the client and the server.
MADCAPクライアントは、すべてのメッセージの再送信を担当しています。クライアントは、再送信の間の遅延を決定するために、指数バックオフアルゴリズムを組み込んだ再送戦略を採用しなければなりません。再送信の間の遅延は、サーバからの応答がクライアントとサーバとの間のインターネットワークの特性に基づいて配信されるのに十分な時間を可能にするように選択されるべきです。
The RECOMMENDED algorithm is to use a 4 second delay before the first retransmission and to double this delay for each successive retransmission, with a maximum delay of 16 seconds and a maximum of three retransmissions. If an initial transmission was sent at time (in seconds) t and no responses were received, subsequent transmissions would be at t+4, t+12, and t+28. If no response has been received by t+60, the client would stop retransmitting and take another course of action (such as logging an error or sending a message to another address.
推奨アルゴリズムは、最初の再送信の前に4秒の遅延を使用し、16秒の最大遅延三の再送の最大で、連続する各再送信のためのこの遅延を倍増することです。初期伝送をt（秒）で送信されたと全く応答が受信されなかった場合、後続の送信は、T + 4、T + 12、およびt + 28であろう。応答がT + 60で受信されていない場合、クライアントは再送信を停止し、（そのようなエラーをログに記録するか、別のアドレスにメッセージを送信すると、アクションの別のコースを取るだろう。
The client MAY provide an indication of retransmission attempts to the user as an indication of the progress of the process. The client MAY halt retransmission at any point.
クライアントは、プロセスの進行状況の指標としてユーザに再送信試行の指示を提供してもよいです。クライアントは、任意の時点での再送信を停止させることができます。
The Lease Identifier option is included in each MADCAP message. Its value is used to identify a lease and MUST be unique across all leases requested by all clients in a multicast address allocation domain.
リース識別子オプションは、各MADCAPメッセージに含まれています。その値は、リースを識別するために使用され、マルチキャストアドレス割り当てドメイン内のすべてのクライアントによって要求されたすべてのリースで一意である必要があります。
The first octet of the Lease Identifier is the Lease Identifier type. Table 3 lists the Lease Identifier types defined at this time and sections 2.4.1 and 2.4.2 describe these Lease Identifier types.
リース識別子の最初のオクテットは、リース識別子タイプです。表3は、今回とセクション2.4.1と2.4.2で定義されたリース識別子の種類は、これらのリース識別子の種類について説明します。
New MADCAP Lease Identifier types may only be defined by IETF Consensus, as described in section 5.
セクション5に記載されているように新しいMADCAPリース識別子タイプのみ、IETF合意によって定義されてもよいです。
Lease Identifier Type Name
--------------------- ----
0 Random Lease Identifier
1 Address-Specific Lease Identifier
Table 3: MADCAP Lease Identifier Types
表3：MADCAPリース識別子データ型
The MADCAP server does not need to parse the Lease Identifier. It SHOULD use the Lease Identifier only as an opaque identifier, which must be unique for each lease. The purpose of defining different Lease Identifier types is to allow MADCAP clients that already have a globally unique address to avoid the possibility of Lease Identifier collisions by using this address together with a client-specific identifier. MADCAP clients that do not have a globally unique address SHOULD use Lease Identifier type 0.
MADCAPサーバーはリース識別子を解析する必要はありません。それは、各リースで一意である必要があり、不透明な識別子としてリース識別子を使用すべきです。異なるリース識別子タイプを定義する目的は、すでにクライアント固有の識別子と一緒に、このアドレスを使用してリース識別子の衝突の可能性を回避するために、グローバルに一意のアドレスを持っているMADCAPクライアントをできるようにすることです。グローバルに一意のアドレスを持っていないMADCAPクライアントがリース識別子タイプ0を使用すべきです。
In addition to associating client and server messages (along with the msgtype and xid fields, as described in the next section), the Lease Identifier is used to determine which lease a RENEW or RELEASE request refers to. MADCAP servers SHOULD match the Lease Identifier included in a RENEW or RELEASE message with the Lease Identifier used in an initial REQUEST message. If the Lease Identifier does not match, a MADCAP server MUST generate and process a Lease Identifier Not Recognized error in the manner described in section 2.6.
（次のセクションで説明したように、MSGTYPEおよびXIDフィールドとともに）クライアントとサーバーメッセージを関連付けることに加えて、リース識別子を更新するか、RELEASE要求が参照リースを決定するために使用されます。 MADCAPサーバはリース識別子が初期要求メッセージで使用されるリース識別子に更新するかRELEASEメッセージに含まれる一致する必要があります。リース識別子が一致しない場合は、MADCAPサーバが生成し、セクション2.6に記載された方法でリース識別子認識されないエラーを処理しなければなりません。
For conferencing applications, it may be desirable to allow conference participants to modify a lease used for the conference. The Shared Lease Identifier feature code is used to support this requirement. If this feature code was requested by the client and implemented by the server when the lease was allocated, the server SHOULD disable any authentication requirements and allow any client that knows the Lease Identifier to modify the lease.
会議アプリケーションの場合は、会議参加者が会議に使用するリースを変更できるようにすることが望ましいことがあります。共有リース識別子の機能コードは、この要件をサポートするために使用されます。この機能コードは、クライアントから要求されたリースが割り当てられたサーバーによって実装された場合、サーバーは任意の認証要件を無効にして、リースを変更するリース識別子を知っているすべてのクライアントを許可する必要があります。
As described in the Security Considerations section, MADCAP security is not terribly useful without admission control in the multicast routing infrastructure. However, if MADCAP security is desired when using the Shared Lease Identifier feature, the confidentiality of the Lease Identifier MUST be maintained by encrypting all messages that contain it. A Lease Identifier that includes a long cryptographically random number (at least eight octets in length) MUST be used in this circumstance so that it is not easy to guess the Lease Identifier.
セキュリティの考慮事項のセクションで説明したように、MADCAPセキュリティは、マルチキャストルーティングインフラストラクチャにおけるアドミッション制御なしにひどく有用ではありません。共有リース識別子機能を使用する場合MADCAPセキュリティが要求される場合には、リース識別子の機密性は、それが含まれているすべてのメッセージを暗号化することによって維持されなければなりません。リース識別子を推測することは容易ではないように、長い暗号乱数を含むリース識別子（長さが少なくとも8オクテット）はこの状況で使用されなければなりません。
The first octet of a Random Lease Identifier is the Lease Identifier type (0 to indicate Random Lease Identifier). After this come a sequence of octets, which SHOULD represent a long random number (at least 16 octets) from a decent random number generator.
ランダムリース識別子の最初のオクテットは、リース識別子タイプ（ランダムリース識別子を示す0）です。この後まともな乱数発生器から長い乱数（少なくとも16オクテット）を表現して下さいオクテットのシーケンスを、来ます。
A Random Lease Identifier does not include any indication of its length. It is assumed that this may be determined by external means, such as a length field preceding the Lease Identifier.
ランダムなリース識別子は、その長さの兆候が含まれていません。そのようなリース識別子に先行する長さフィールドなどの外部手段によって決定されてもよいことが想定されます。
Lease ID
Type Random Number
+---------+-------------...
| 0 |
+---------+-------------...
The first octet of an Address-Specific Lease Identifier is the Lease Identifier type (1 to indicate Address-Specific Lease Identifier). After this comes a two octet IANA-defined address family number (including those defined in [10]), an address from the specified address family, and a client-specific identifier (such as a sequence number or the current time).
住所、特定のリース識別子の最初のオクテットは、リース識別子タイプ（アドレス、特定のリース識別子を示す1）です。これは（[10]で定義されたものを含む）は、2つのオクテットIANAに定義されたアドレスファミリー番号、指定されたアドレスファミリからのアドレス、および（例えば、シーケンス番号や現在時刻など）は、クライアント固有の識別子を来ました。
An Address-Specific Lease Identifier does not include any indication of its length. It is assumed that this may be determined by external means, such as a length field preceding the Lease Identifier.
住所、特定のリース識別子は、その長さの兆候が含まれていません。そのようなリース識別子に先行する長さフィールドなどの外部手段によって決定されてもよいことが想定されます。
Lease ID Address Family Address Client-specific
Type Number Identifier
+---------+---------+---------+-----...-----+-----...-----+
| 1 | addrfamily | address | cli-spec id |
+---------+---------+---------+-----...-----+-----...-----+
Messages between clients and servers are associated with one another using the Lease Identifier and the xid field. As described in section 2.1.4, the client MUST choose an xid so that it is unlikely that the same combination of xid, msgtype, and Lease Identifier will be used for two different messages within [XID-REUSE-INTERVAL] (even across multiple clients which do not communicate among themselves). The Lease Identifier option, msgtype, and xid field MUST be included in each message sent by the client or the server.
クライアントとサーバー間のメッセージは、リース識別子とXIDフィールドを使用して相互に関連付けされています。セクション2.1.4で説明したように、XID、MSGTYPE、及びリース識別子の同一の組み合わせが（偶数倍横切っ[XID - REUSE - INTERVAL]内の2つの異なるメッセージのために使用されることはありそうもないように、クライアントは、XIDを選択する必要があります相互に通信していないクライアント）。リース識別子オプション、MSGTYPE、およびXIDフィールドは、クライアントまたはサーバによって送信される各メッセージに含まれなければなりません。
The client MUST check the Lease Identifier option and xid field in each incoming message to ensure that they match the Lease Identifier and xid for an outstanding transaction. If not, the message MUST be ignored. The server MUST check the Lease Identifier option and xid field in each incoming message to establish the proper context for the message. If a server cannot process a message because it is invalid for its context, the server MUST generate and process an Invalid Request error, as described in section 2.6. A transaction can be an attempt to allocate a multicast address (consisting of DISCOVER, OFFER, REQUEST, ACK, and NAK messages), an attempt to renew a lease (consisting of RENEW, ACK, and NAK messages), an attempt to release a previously allocated multicast address (consisting of RELEASE, ACK, and NAK messages), or an attempt to acquire configuration parameters (consisting of GETINFO, ACK, and NAK messages).
クライアントは、彼らが優れた取引のリース識別子とXIDと一致していることを保証するために、各受信メッセージにリース識別子オプションおよびXIDフィールドをチェックしなければなりません。そうでない場合、メッセージは無視しなければなりません。サーバーは、メッセージのための適切なコンテキストを確立するために、各受信メッセージにリース識別子オプションおよびXIDフィールドをチェックしなければなりません。それは、そのコンテキストのために無効であるため、サーバーはメッセージを処理できない場合、セクション2.6で説明したように、サーバーは、無効なリクエストエラーを生成して処理しなければなりません。トランザクションが（DISCOVER、OFFER、REQUEST、ACK、およびNAKメッセージからなる）マルチキャストアドレスを割り当てるための試み、（RENEW、ACK、およびNAKメッセージからなる）リースを更新しようとすると、解放する試みであることができます以前に割り当てられたマルチキャストアドレス（RELEASE、ACK、及びNAKメッセージからなる）、またはコンフィギュレーションパラメータ（GETINFO、ACK、及びNAKメッセージからなる）を取得しようとします。
If a MADCAP server encounters an error while processing a message, there are two different ways to process this error. If it is clear that the message is not a NAK, the server SHOULD respond with a NAK containing the appropriate Error option. However, the server MAY decide to completely ignore chronic offenders. If the message is a NAK or it is not clear whether the message is a NAK (for instance, the message is garbled or has an incorrect version number), the server SHOULD ignore the message. This avoids NAK loops.
メッセージの処理中MADCAPサーバはエラーが発生した場合、このエラーを処理するための2つの異なる方法があります。それは、メッセージがNAKではないことは明らかである場合は、サーバが適切なエラー・オプションを含むNAKで応答する必要があります。しかし、サーバが完全に慢性的犯罪者を無視するように決定することができます。メッセージがNAKであるか、またはメッセージがNAKであるかどうかは明らかではない場合、サーバはメッセージを無視すべきである（例えば、メッセージが文字化けしているか、間違ったバージョン番号を有します）。これは、NAKループ回避できます。
If a MADCAP client encounters an error while processing a message, it MUST ignore the message.
メッセージの処理中にMADCAPクライアントでエラーが発生した場合は、メッセージを無視しなければなりません。
RFC 2365 [3] provides for dividing the multicast address space into a number of administrative scopes. Routers should be configured so that each scope corresponds to a particular partition of the network into disjoint regions. Messages sent to a multicast address that falls within a certain administrative scope should only be delivered to hosts that have joined that multicast group *and* fall within the same region as the sender. For instance, packets sent to an address in the organization-local scope should only be delivered to hosts that have joined that group and fall within the same organization as the sender.
RFC 2365 [3]の管理スコープの数にマルチキャストアドレス空間を分割することを提供します。各範囲は互いに素の領域にネットワークの特定のパーティションに対応するようにルータが設定されなければなりません。特定の管理範囲内にあるマルチキャストアドレスに送信されたメッセージは、送信者と同じ領域内のマルチキャストグループ*と*落下こと参加しているホストに配信されなければなりません。例えば、組織ローカルスコープ内のアドレスに送信されたパケットは、そのグループに参加し、送信者と同じ組織内に入るたホストに配信されなければなりません。
Different sets of scopes may be in effect at different places in the network and at different times. Before attempting to allocate an address from an administrative scope (other than global or link-level scope, which are always in effect), a MADCAP client SHOULD determine that the scope is in effect at its location at this time. Several techniques that a MADCAP client may use to determine the set of administrative scopes in effect (the scope list) are: manual configuration or configuration via MADCAP (using the Multicast Scope List option).
スコープの異なるセットは、ネットワーク内の異なる場所で異なる時間で有効であってもよいです。 （実際には常にグローバルまたはリンクレベルスコープ以外）の管理範囲からアドレスを割り当てる前に、MADCAPクライアントは範囲が、現時点ではその場所で有効であることを決定しなければなりません。 MADCAPクライアントが有効な管理スコープのセット（スコープリスト）を決定するために使用することができますいくつかの技術は、以下のとおりです。MADCAPを経由して手動設定または構成（マルチキャストスコープ一覧オプションを使用します）。
If a MADCAP client is unable to determine its scope list using one of these techniques, it MAY temporarily assume a scope list consisting of a single scope. If it is using IPv4, it SHOULD use IPv4 Local Scope (239.255.0.0/16), with a maximum TTL of 16. If it is using IPv6, it SHOULD use SCOP 3, with a maximum hop count of 16. Using this temporary scope list, it MAY attempt to contact a MADCAP server that can provide a scope list for it.
MADCAPクライアントは、これらの技術のいずれかを使用してその範囲のリストを決定できない場合は、一時的に単一のスコープからなるスコープのリストをとることができます。それは、IPv4を使用している場合は、IPv6を使用している場合、それは16の最大TTLを用いて、IPv4のローカルスコープ（239.255.0.0/16）を使用する必要があり、それはこの一時的を使用し16の最大ホップカウントと、SCOP 3を使用すべきですスコープリストは、それはそれのためのスコープのリストを提供することができますMADCAPサーバーに連絡しようとすることができます。
When a MADCAP client requests an address with a DISCOVER or REQUEST message, it MUST specify the administrative scope from which the address should be allocated. This scope is indicated with the Multicast Scope option. Likewise, the server MUST include the Multicast Scope option in all OFFER messages and all ACK messages sent in response to REQUEST messages.
MADCAPクライアントがDISCOVERかREQUESTメッセージとアドレスを要求すると、それはアドレスが割り当てられるべきで、そこから管理スコープを指定しなければなりません。このスコープは、マルチキャストスコープオプションで示されています。同様に、サーバはすべてのOFFERメッセージとメッセージを要求に応じて送信されたすべてのACKメッセージにおけるマルチキャストスコープオプションを含まなければなりません。
Another way to limit propagation of multicast messages is by using TTL scoping. This technique has several disadvantages in comparison to administratively scoped multicast addresses (as described in [3]), but it is currently in widespread usage.
マルチキャストメッセージの伝播を制限する別の方法は、TTLスコープを使用することです。この技術は、それが普及使用中である（[3]に記載のように）管理マルチキャストアドレススコープと比較していくつかの欠点を有します。
With TTL scoping, areas of the network are designated as scopes. Routers on the edges of these areas are configured with TTL thresholds so that multicast packets are not forwarded unless their remaining TTL exceeds this threshold. A packet which should be restricted to a given TTL scope should have an initial TTL less than that scope's TTL threshold. Similar techniques may be used with IPv6, using the Hop Count field instead of the TTL field.
TTLスコープを使用すると、ネットワークの領域は、スコープとして指定されています。その残りのTTLがこのしきい値を超えない限り、マルチキャストパケットが転送されないように、これらの領域のエッジ上のルータは、TTLしきい値が設定されています。与えられたTTLスコープに制限されるべきパケットは、そのスコープのTTLの閾値未満の初期TTLを持つ必要があります。同様の技術は、ホップカウントフィールドの代わりに、TTLフィールドを使用して、IPv6で使用されてもよいです。
MADCAP may be used in an environment where administrative scoping is not in use and TTL scoping is. Under these circumstances, a MADCAP server MAY return a scope list that includes scopes with TTLs less than 255. The MADCAP client MAY then allocate addresses from these scopes, but MUST NOT set the TTL field of any packet sent to such an address to a value greater than the maximum TTL indicated in the scope list. In such an environment, it is recommended that the MADCAP Server Multicast Addresses associated with the IPv4 Local Scope (or SCOP 3 for IPv6) be configured using TTL thresholds so that packets sent to these addresses with TTL of 16 are not sent outside an appropriate boundary. This will allow MADCAP clients to use their default behavior for finding MADCAP servers.
MADCAPは、管理スコープが使用されておらず、TTLスコープがある環境で使用することができます。このような状況下では、MADCAPサーバはTTLを持つスコープを含むスコープのリストを返してもよいMADCAPクライアントは、その後、これらのスコープからアドレスを割り当てることができるが、その値にこのようなアドレスに送信されたパケットのTTLフィールドを設定してはいけません255より小さいスコープリストに示さ最大TTLよりも大きいです。このような環境では、16のTTLと、これらのアドレスに送信されたパケットは、適切な境界の外に送信されないように、IPv4のローカルスコープ（またはIPv6のSCOP 3）に関連MADCAPサーバマルチキャストアドレスはTTLしきい値を使用して設定することが推奨されます。これはMADCAPクライアントはMADCAPサーバを見つけるために彼らのデフォルトの動作を使用できるようになります。
In an environment where administrative scoping is in use, the maximum TTLs in the scope list SHOULD be 255. The admin scope zone boundary routers will prevent leakage of MADCAP packets beyond appropriate limits.
管理スコープを使用している環境では、スコープのリストで最大のTTLは、管理スコープゾーン境界ルータが適切な限界を超えてMADCAPパケットの漏洩を防ぐことができます255であるべきです。
There are several ways for a MADCAP client to locate a MADCAP server. For instance, the client may be configured with an IP address.
MADCAPサーバーを見つけるためにMADCAPクライアントのためのいくつかの方法があります。例えば、クライアントはIPアドレスで設定することができます。
The RECOMMENDED technique is for the client to send an GETINFO message to a MADCAP Server Multicast Address and wait for ACK responses. This technique is described in more detail in the next section.
推奨技術はMADCAPサーバーのマルチキャストアドレスにGETINFOメッセージを送信し、ACK応答を待つクライアントのためです。この技術は、次のセクションでより詳細に説明します。
Each multicast scope has an associated MADCAP Server Multicast Address. This address has been reserved by the IANA as the address with a relative offset of -1 from the last address of a multicast scope.
各マルチキャストスコープは、関連するMADCAPサーバーのマルチキャストアドレスを持っています。このアドレスは、マルチキャストスコープの最後のアドレスから-1の相対オフセットを持つアドレスとしてIANAによって予約されています。
A MADCAP client looking for servers that can provide multicast allocation services MAY send an GETINFO message to a MADCAP Server Multicast Address. Any MADCAP servers listening to this address SHOULD respond with a unicast ACK message to the client if they wish to offer a response.
マルチキャスト割り当てサービスを提供できるサーバを探しているMADCAPクライアントはMADCAPサーバーのマルチキャストアドレスにGETINFOメッセージを送信することができます。彼らは応答を提供する場合は、このアドレスを聞いてどれMADCAPサーバは、クライアントへのユニキャストACKメッセージで応答する必要があります。
The MADCAP Server Multicast Address used by a client MAY be established by configuration. If a client has no such configuration, it SHOULD use the MADCAP Server Multicast Address associated with IPv4 Local Scope (or SCOP 3 for IPv6) with maximum TTL of 16, unless otherwise configured.
クライアントが使用するMADCAPサーバーのマルチキャストアドレスは、コンフィギュレーションによって確立することができます。クライアントは、そのような構成を有していない場合は特に設定しない限り、それは、16の最大TTLとIPv4のローカルスコープ（またはIPv6のSCOP 3）に関連MADCAPサーバーのマルチキャストアドレスを使用する必要があります。
If a client receives no response to a message sent to a MADCAP Server Multicast Address (after retransmission), it MAY send the message to a larger scope and repeat this process as necessary. However, the client MUST NOT send a MADCAP message to the MADCAP Server Multicast Address associated with the global scope.
クライアントが（再送後）MADCAPサーバーのマルチキャストアドレスに送信されたメッセージへの応答がない場合、それはより大きなスコープにメッセージを送信し、必要に応じて、このプロセスを繰り返すことができます。ただし、クライアントがグローバルスコープに関連付けられているMADCAPサーバーのマルチキャストアドレスにMADCAPメッセージを送ってはいけません。
This technique allows MADCAP servers to provide services for scopes in which they do not reside. However, this is a dangerous and complicated technique and is NOT RECOMMENDED at this time. Therefore, MADCAP clients SHOULD only send multicast messages to the MADCAP Server Multicast Address corresponding to the IPv4 Local Scope (or SCOP 3, if using IPv6), unless configured otherwise.
この技術はMADCAPサーバは、それらが存在しない中でスコープのためのサービスを提供することができます。ただし、これは危険で複雑な技術であり、この時点ではお勧めしません。別段構成しない限り、（IPv6を使用している場合、またはSCOP 3）したがって、MADCAPクライアントは、IPv4のみローカルスコープに対応MADCAPサーバマルチキャストアドレスにマルチキャストメッセージを送信すべきです。
MADCAP servers that wish to provide services for scopes in which they do not reside MUST make special efforts to ensure that their services meet clients' needs for largely conflict-free allocation and accurate scope list information. In particular, coordinating with other servers that provide services for this scope may be difficult. Also, establishing which scope the client is in may be difficult. If a MADCAP server is not prepared to provide services for scopes in which it does not reside, it SHOULD ignore DISCOVER and REQUEST messages whose scope does not match or enclose the scope of the MADCAP Server Multicast Address on which the request was received. It SHOULD also ignore GETINFO messages that are not received on the MADCAP Server Multicast Address for IPv4 Local Scope.
それらが存在しない中でスコープのためのサービスを提供したいMADCAPサーバは、そのサービスは、主に競合のない配分と正確な範囲リスト情報のための顧客のニーズを満たしていることを確認するために特別な努力をしなければなりません。特に、このスコープのためのサービスを提供する他のサーバと連携することは難しいかもしれません。また、クライアントがどの範囲を確立することは困難であろう。 MADCAPサーバーは、それが存在しないようなスコープのためのサービスを提供する準備ができていない場合は、DISCOVER、その範囲と一致するか、要求を受信したMADCAPサーバーのマルチキャストアドレスの範囲を囲みませんREQUESTメッセージを無視すべきです。また、IPv4のローカルスコープのためのMADCAPサーバーのマルチキャストアドレスで受信されていないGETINFOメッセージを無視すべきです。
The Current Time option is used to detect and handle clock skew between MADCAP clients and servers. This option MUST be included in any MADCAP message that includes an absolute time (such as the Start Time option). It MAY be included in any DISCOVER, OFFER, REQUEST, RENEW, or ACK message.
現在の時刻オプションはMADCAPクライアントとサーバ間のクロック・スキューを検出し、処理するために使用されます。このオプションは、（例えば、開始時間オプションとして）絶対時間を含む任意のMADCAPメッセージに含まれなければなりません。これは、任意のDISCOVER、OFFER、REQUEST、RENEW、またはACKメッセージに含まれるかもしれません。
Clock skew is a situation where two systems have clocks that are not synchronized. Many protocols (such as DHCP) ignore clock skew by using relative times. MADCAP could use a similar technique, but this leads to nasty situations due to the way multicast addresses are used.
クロック・スキューは、2つのシステムが同期されていない時計を持っている状況です。 （DHCPなど）多くのプロトコルは、相対時間を用いてクロック・スキューを無視します。 MADCAPは、同様の手法を使用することができますが、これはマルチキャストアドレスが使用されている方法が原因厄介な状況につながります。
For example, assume that at 1 PM UTC a client whose clock is one hour fast requests a lease for one hour starting in one hour. If we were using relative times for MADCAP, the server, whose clock is set correctly, would reserve a multicast address for 2 to 3 PM UTC and grant the request. If the client was the only one using the lease, everything would be OK. The client would start using the lease in one hour and continue for one hour. This would coincide with the time the server had reserved (although the client would think it was 3 to 4 PM UTC).
例えば、1 PM UTCにそのクロック1時間で開始1時間1時間の速い要求リースであるクライアントをのことを想定しています。私たちはMADCAPのための相対時間を使用していた場合は、その時計が正しく設定されているサーバは、2〜3 PM UTCのためのマルチキャストアドレスを予約して、要求を許可します。クライアントがリースを使用してだけだった場合は、すべてがOKになります。クライアントは、1時間でのリースの使用を開始し、1時間継続します。これは、サーバーが予約した時間（クライアントが4 PM UTCに3だったと思うだろうが）と一致するでしょう。
However, multicast addresses are usually used by several parties at once. The client would probably use SAP (or some other mechanism for conveying SDP) to advertise a session using the multicast address just leased. SDP uses absolute times, since it may be sent via email, web, or other store-and-forward mechanisms. So the client would advertise the session as running from 3 to 4 PM UTC. Any clients whose clocks are set correctly would use the address during this interval. Since the server only reserved the address from 2 to 3 PM UTC, this might cause the address to be used for multiple sessions simultaneously.
しかし、マルチキャストアドレスは通常、一度に複数の当事者によって使用されています。クライアントは、おそらくリースマルチキャストアドレスを使用してセッションを宣伝するためにSAP（またはSDPを搬送するためのいくつかの他のメカニズム）を使用します。それは、電子メール、ウェブ、または他のストアアンドフォワードメカニズムを介して送信することができるので、SDPは、絶対時間を使用します。だから、クライアントが3から4 PM UTCに実行されているように、セッションを宣伝でしょう。その時計が正しく設定されているすべてのクライアントは、この期間中にアドレスを使用します。サーバはわずか2から3 PM UTCにアドレスを予約しているので、これはアドレスが同時に複数のセッションに使用されることがあります。
MADCAP cannot solve all clock skew problems. That is the domain of NTP [4]. However, it does attempt to detect substantial clock skew between MADCAP clients and servers so that this clock skew does not cause massive collisions in multicast address usage later on.
MADCAPは、すべてのクロック・スキューの問題を解決することはできません。それは、NTP [4]のドメインです。しかし、それはこのクロック・スキューが、後に、マルチキャストアドレスの使用で大規模な衝突を起こさないように、MADCAPクライアントとサーバとの間に実質的なクロック・スキューを検出しようとしません。
The Current Time option contains the sender's opinion of the current time in UTC at or about the time the message was assembled. Because of delays in transmission and processing, this value will rarely match the receiver's opinion of the current time at the time the option is processed by the receiver. However, difference greater than a minute or two probably indicate clock skew between the sender and the receiver.
現在の時刻オプションは、メッセージが組み立てた時点で約UTCの現在時刻の送信者の意見が含まれています。そのため、送信および処理の遅れにより、この値はほとんどのオプションは、受信機によって処理された時点で、現在の時刻の受信者の意見が一致しません。しかし、1,2分よりも大きい違いは、おそらく送信者と受信者の間のクロック・スキューを示しています。
MADCAP servers SHOULD expect and tolerate a small amount of clock skew with their clients by ensuring that multicast addresses are allocated for an extra period of time [EXTRA-ALLOCATION-TIME] on either side of the lease given to the client. However, large amounts of clock skew require special handling. The value of [EXTRA-ALLOCATION-TIME] MUST be a configurable parameter, since local circumstances may vary. The RECOMMENDED default is one hour.
MADCAPサーバは、期待とマルチキャストアドレスがクライアントに与えられたリースのいずれかの側の時間の余分な期間[EXTRA-ALLOCATION-TIME]のために割り当てられていることを確実にすることにより、顧客とのクロック・スキューの少量を容認すべきです。ただし、クロック・スキューの大量の特別な処理を必要とします。ローカル環境が変化し得るので[EXTRA割り当て-TIME]の値は、設定可能なパラメータでなければなりません。推奨されるデフォルトは1時間です。
However, large amounts of clock skew will cause problems later when sessions are advertised. If a MADCAP server detects clock skew greater than [CLOCK-SKEW-ALLOWANCE], it MUST generate and process an Excessive Clock Skew error, as described in section 2.6. The server MAY also log a message. The value of [CLOCK-SKEW-ALLOWANCE] MUST be a configurable parameter, since local circumstances may vary. The
セッションが宣伝されている場合ただし、クロック・スキュー大量のは後に問題が発生します。 MADCAPサーバがクロックを検出した場合、[CLOCK-SKEW-ALLOWANCE]より大きいスキューセクション2.6で説明したように、それは、過度のクロックスキューエラーを生成して処理しなければなりません。また、サーバは、メッセージを記録することがあります。ローカル環境が変化し得るので[CLOCK-SKEW-ALLOWANCE]の値は、設定可能なパラメータでなければなりません。ザ・
RECOMMENDED default is 30 minutes.
推奨されるデフォルトは30分です。
Each MADCAP client or server MAY implement one or more optional features. Optional features of MADCAP are identified with a two octet feature code.
各MADCAPクライアントまたはサーバは、1つまたは複数のオプション機能を実装してもよいです。 MADCAPのオプション機能は、2つのオクテットの機能コードで識別されています。
A MADCAP client MAY request, require, or indicate support for an optional feature by including a Feature List option in a message. For more information about optional features, see the description of the Feature List option.
MADCAPクライアントは、リクエストが必要です、またはメッセージで機能リストのオプションを含めることによって、オプション機能のサポートを示すことがあります。オプション機能の詳細については、機能リストのオプションの説明を参照してください。
Table 4 lists the feature codes defined at this time and sections 2.13.1 and 2.13.2 describe how these features work.
表4は、この時点で定義された機能コードとセクション2.13.1と2.13.2は、これらの機能がどのように動作するかを説明します。
New MADCAP feature codes may only be defined by IETF Consensus, as described in section 5.
セクション5に記載されているように新しいMADCAP機能コードのみ、IETF合意によって定義されてもよいです。
Feature Code Feature Name
------------ ------------
0 Server Mobility
1 Retry After
2 Shared Lease Identifier
Table 4: MADCAP Feature Codes
表4：MADCAP機能コード
The Server Mobility feature allows an address allocated on one MADCAP server to be renewed or released on a different MADCAP server. This requires communication and coordination among MADCAP servers. The primary benefits are immunity to the failure of a single MADCAP server and perhaps greater performance through load balancing.
サーバーのモビリティ機能は、1台のMADCAPサーバーに割り当てられたアドレスが異なるMADCAPサーバー上で更新または解放することができます。これはMADCAPサーバ間の通信との連携が必要です。主な利点は、単一のMADCAPサーバと負荷分散を通じて、おそらくそれ以上の性能の故障に対する耐性があります。
In order to take advantage of the Server Mobility feature, a MADCAP client must ensure that the feature is implemented by both the server that is used for the original allocation and the server that is used for the renewal or release. The best way to ensure this is to include the Server Mobility feature in the required list of a Feature List option in the REQUEST message used to allocate the address (and the DISCOVER message, if one is used). When the time comes to renew or release the address, the client SHOULD send a unicast RENEW or RELEASE message to the server from which it allocated the address. However, if this server is unavailable, the client MAY send the RENEW or RELEASE message to any other server that includes the Server Mobility feature in its list of supported features. The client can find such a server by (for instance) sending an GETINFO message with an Option Request List option that includes the Feature List option code.
サーバーのモビリティ機能を利用するためには、MADCAPクライアントは機能は、元の割り当てに使用されているサーバと更新または解放のために使用されているサーバーの両方で実装されていることを確認する必要があります。これを確保するための最善の方法は、（1が使用されている場合、およびDISCOVERメッセージ）アドレスを割り当てるために使用される要求メッセージに機能リストオプションの必要なリストでサーバーのモビリティ機能を含めることです。時間はアドレスを更新またはリリースになると、クライアントがRENEWか、それがアドレスを割り当てられ、そこからサーバーにメッセージを解放し、ユニキャストを送るべきです。このサーバーが利用できない場合は、クライアントがサポートされている機能のリストにあるサーバのモビリティ機能を含む任意の他のサーバーにRENEWかRELEASEメッセージを送信することができます。クライアントは、機能リストのオプションコードを含んオプション要求リストオプションでGETINFOメッセージを送信する（例えば）によって、このようなサーバーを見つけることができます。
If the MADCAP client does not want to require this feature when allocating addresses, it may include the feature in the requested list of a Feature List option and see if the server includes the feature in the required list of a Feature List option in the ACK message.
MADCAPクライアントがアドレスを割り当てる際に、この機能を必要としたくない場合は、機能リストのオプションの要求リストに機能を含むことができ、サーバはACKメッセージで機能リストオプションの必要なリスト内の機能が含まれている場合に表示さ。
Even if the Server Mobility feature is used, there is no guarantee that a server will be available to perform the renewal or release or that the renewal or release will succeed. Server connectivity may have failed, for instance.
サーバーのモビリティ機能を使用している場合でも、サーバは更新を実行したり、解放したり更新やリリースが成功することをするために利用できるようになります保証はありません。サーバーとの接続は、例えば、失敗した可能性があります。
The Retry After feature allows a MADCAP server to ask the MADCAP client to retry its request later, as may be required when allocating large numbers of addresses or allocating addresses for a long period of time.
機能の後にリトライはアドレスの多数の割り当てや長時間のアドレスを割り当てる際に必要とされるようMADCAPサーバは、後でその要求を再試行するMADCAPクライアントに依頼することができます。
For instance, if a MADCAP client requests 1000 addresses, administrative approval may be required or allocation of more addresses from another MASC domain may be necessary. This may take several hours or several days. If the MADCAP client and server both support the Retry After feature, the MADCAP server can send back an ACK message with a Retry Time option indicating when the addresses may be ready. The client can retry its request after the Retry Time to get the addresses.
MADCAPクライアントが1000個のアドレスを要求した場合たとえば、管理者の承認が必要になることがありますか、別のMASCのドメインからの複数のアドレスの割り当てが必要になることがあります。これは、数時間または数日かかる場合があります。 MADCAPクライアントとサーバの両方が機能した後の再試行をサポートしている場合、MADCAPサーバは、アドレスは準備ができていることを示すとき、再試行時間オプションを使用してACKメッセージを送り返すことができます。クライアントがアドレスを取得するために再試行時間後にその要求を再試行することができます。
If a MADCAP client includes the Retry After feature in the supported list of a Feature List option in a REQUEST message, a MADCAP server that supports the Retry After feature MAY decide to begin a lengthy allocation process. In this case, the MADCAP server will include an empty List of Address Ranges option in its ACK message, a Feature List option that includes the Retry After feature in the required list, and a Retry Time option with a time after which the client should retry the REQUEST.
MADCAPクライアントが要求メッセージに機能リストオプションのサポートリストで機能した後の再試行が含まれている場合は、機能した後の再試行をサポートしているMADCAPサーバは、長い割り当てプロセスを開始することを決定してもよいです。この場合、MADCAPサーバは、そのACKメッセージにオプションをアドレス範囲の空の一覧、必要なリストで機能した後の再試行を含ん機能リストオプション、およびクライアントが再試行するまでの時間と再試行時間のオプションが含まれますリクエスト。
The client MUST NOT include the Retry After feature in the requested or required list of a Feature List option, since the decision about whether Retry After is desirable should be left to the MADCAP server.
再試行の後に望ましいかどうかについての決定がMADCAPサーバーに残さなければならないので、クライアントは、機能リストのオプションの要求または必要なリストにフィーチャーした後の再試行を含んではいけません。
At some later time (preferably after the time indicated in the Retry Time option), the client SHOULD send a REQUEST message with all the same options as the original REQUEST message (especially the Lease Identifier option), but with a new xid value. The server MAY return a normal ACK or NAK message at this point or it MAY continue the transaction to a later time by including an empty List of Address Ranges option in its ACK message, a Feature List option that includes the Retry After feature in the required list, and a Retry Time option with a later time after which the client should retry the REQUEST.
いくつかの後の時間（好ましく時間後にリトライ時間オプションに示されている）で、クライアントは元の要求メッセージ（特にリース識別子オプション）などが、新しいxid値を持つすべて同じオプションを使用してREQUESTメッセージを送るべきです。サーバーは、この時点で、通常のACKまたはNAKメッセージを返す場合もあれば、アドレスの空のリストを含むことによって、後で時間に取引を続けてACKメッセージ、必要で機能した後の再試行を含ん機能一覧オプションでオプションを範囲MAYリスト、およびクライアントが要求を再試行する必要があり、その後、後で再試行して時間オプション。
At any point after receiving the initial ACK message with the Retry Time option, the client MAY terminate the allocation process and any accompanying lease by sending to the server performing the allocation (or another server if the Server Mobility feature is also in effect) a RELEASE message with the Lease Identifier included in the original REQUEST message.
RELEASE（サーバのモビリティ機能が有効でもある場合、または別のサーバー）の再試行時間オプションを使用して、最初のACKメッセージを受信した後の任意の時点で、クライアントは、割り当てプロセスと配分を実行するサーバに送信することにより、任意の添付リースを終了することができリース識別子を持つメッセージは、元の要求メッセージに含まれます。
The Retry After feature may also be used when renewing a lease. In this case, the description above applies except that the client sends a RENEW message instead of a REQUEST message.
リースを更新する際に機能した後に再試行を使用することもできます。この場合は、上記の説明では、クライアントの代わりにREQUESTメッセージのRENEWメッセージを送信することを除いて適用されます。
If a client sends a RENEW message with a Lease Identifier that matches a lease which is currently undergoing allocation with the Retry After feature in response to a REQUEST message, the server MUST generate and process an Invalid Request error in the manner described in section 2.6. Also, if a client sends a RENEW message with a Lease Identifier that matches a lease which is currently undergoing allocation with the Retry After feature in response to a RENEW message, but the options supplied with the two RENEW messages do not match, the server MUST generate and process an Invalid Request error in the manner described in section 2.6.
クライアントが現在要求メッセージに応答して機能した後に再試行との割り当てを受けているリースを一致リース識別子で更新メッセージを送信すると、サーバは、セクション2.6に記載の方法で無効なリクエストエラーを生成して処理しなければなりません。また、クライアントは現在、2件のRENEWメッセージが一致しないと、サーバはMUST RENEWメッセージに応答して機能した後に再試行して割り当てを受けますが、オプションが供給されているリースに一致するリース識別子とRENEWメッセージを送信する場合生成し、セクション2.6に記載の方法で無効なリクエストエラーを処理します。
Note that the Retry After feature may complicate the application API. For this reason, a MADCAP client may request the Retry After feature for some messages and not for others. This should not cause problems for a robust MADCAP server. In general, servers should not expect consistent behavior from clients except as required by this specification. This also applies to clients' expectations.
リトライ機能した後のアプリケーションのAPIを複雑にする可能性があることに注意してください。このため、MADCAPクライアントは、いくつかのメッセージのためではなく他人のために機能した後の再試行を要求することができます。これは、堅牢なMADCAPサーバーに問題が発生することはありません。一般的には、サーバは、この仕様によって義務付けられる場合を除き、クライアントからの一貫性のある行動を期待すべきではありません。これはまた、顧客の期待に適用されます。
For conferencing applications, it may be desirable to allow conference participants to modify a lease used for the conference. The Shared Lease Identifier feature code is used to support this requirement.
会議アプリケーションの場合は、会議参加者が会議に使用するリースを変更できるようにすることが望ましいことがあります。共有リース識別子の機能コードは、この要件をサポートするために使用されます。
If this feature code was requested by the client and implemented by the server when the lease was allocated, the server SHOULD disable any authentication requirements pertaining to this lease, allowing any client that knows the Lease Identifier to modify the lease.
この機能コードは、クライアントから要求されたリースが割り当てられたサーバーによって実装された場合、サーバはリースを変更するためにリース識別子を知っている任意のクライアントを許可する、このリースに関連するすべての認証要件を無効にする必要があります。
A MADCAP client wishing to use the Shared Lease Identifier feature should include this feature in the requested or required lists of the Feature List option of a REQUEST message when first allocating the lease. If the feature was required, the server SHOULD try to implement it for this request and include the feature in the required list of the response. If the server can not implement the feature for this request, it MUST generate and process a Required Feature Not Supported error in the manner described in section 2.6. If the feature was requested, the server SHOULD try to implement the feature and include the feature in the required list of the response. However, if the server cannot implement the feature, it may simply skip it.
最初のリースを割り当てる際に、共有リース識別子機能を使用したいMADCAPクライアントは、要求メッセージの機能一覧オプションの要求や必要なリストでこの機能を含める必要があります。機能が必要とされた場合、サーバはこの要求のためにそれを実装しようと応答の必要なリストに特徴を含むべきです。サーバはこの要求の機能を実装することができない場合は、それが生成し、セクション2.6に記載された方法でエラーがサポートされていない必須の機能を処理しなければなりません。機能が要求された場合、サーバは機能を実装しようとすると、応答の必要なリストに特徴を含むべきです。サーバが機能を実装することができない場合は、それは単にそれをスキップすることができます。
Subsequent requests pertaining to a lease for which the Shared Lease Identifier feature was implemented at allocation time MAY include the Shared Lease Identifier feature in the requested or required lists of the Feature List option. In this case, the server SHOULD try to implement the feature by disabling any authentication requirements pertaining to this lease, allowing any client that knows the Lease Identifier to modify the lease, and including the feature in the required list of the response. If the server cannot implement the feature, it SHOULD skip it if the feature was requested. But if the feature was required and the server cannot implement it, the server MUST generate and process a Required Feature Not Supported error in the manner described in section 2.6.
共有リース識別子機能が割り当て時に実装されたため、リースに関連する後続の要求は、機能リストのオプションの要求または必要なリストに共有リース識別子機能を含むかもしれません。この場合、サーバは、このリースに関連するすべての認証要件を無効にリースを変更するためにリース識別子を知っている任意のクライアントを許可し、応答の必要なリストに特徴を含めることによって、機能を実装してみてください。サーバが機能を実装することができない場合は機能が要求された場合、それを飛ばしてください。機能が必要とされた、サーバがそれを実装することができない場合でも、サーバが生成し、セクション2.6に記載された方法でエラーがサポートされていない必須の機能を処理しなければなりません。
As described earlier, each MADCAP message includes an options field consisting of a list of tagged parameters that are called "options". All options consist of a two octet option code and a two octet option length, followed by the number of octets specified by the option length.
前述したように、各MADCAPメッセージは、「オプション」と呼ばれるタグ付きパラメータのリストからなるオプションフィールドを含みます。すべてのオプションは、オプションの長さで指定されたオクテットの数に続く、2つのオクテットのオプションコードと2つのオクテットオプションの長さで構成されています。
This section defines a set of option codes for use in MADCAP messages. New options may be defined using the process defined in section 5. The options are listed in numerical order.
このセクションでは、MADCAPメッセージで使用するためのオプションコードのセットを定義します。新しいオプションは、オプションが番号順にリストされているセクション5で定義されたプロセスを使用して定義することができます。
Table 5 summarizes which options are allowed with each message type.
表5は、各メッセージタイプで許可されているオプションを要約しています。
Option GETINFO ACK (in response to GETINFO)
------ ------ ---------------------------
Lease Time MUST NOT MUST NOT
Server Identifier MUST NOT MUST
Lease Identifier MUST MUST
Multicast Scope MUST NOT MUST NOT
Option Request List MUST MUST NOT
Start Time MUST NOT MUST NOT
Number of Addresses
Requested MUST NOT MUST NOT
Requested Language MAY MUST NOT
Multicast Scope List MUST NOT MAY
List of Address Ranges MUST NOT MUST NOT
Current Time MUST NOT MAY
Feature List MAY MAY
Retry Time MUST NOT MUST NOT
Minimum Lease Time MUST NOT MUST NOT
Maximum Start Time MUST NOT MUST NOT
Error MUST NOT MUST NOT
Option DISCOVER OFFER
------ -------- -----
Lease Time MAY MUST
Server Identifier MUST NOT MUST
Lease Identifier MUST MUST
Multicast Scope MUST MUST
Option Request List MUST NOT MUST NOT
Start Time MAY MAY
Number of Addresses
Requested MAY MUST NOT
Requested Language MUST NOT MUST NOT
Multicast Scope List MUST NOT MUST NOT
List of Address Ranges MAY MAY
Current Time MAY MAY
Feature List MAY MAY
Retry Time MUST NOT MUST NOT
Minimum Lease Time MAY MUST NOT
Maximum Start Time MAY MUST NOT
Error MUST NOT MUST NOT
Option REQUEST ACK (in response to REQUEST)
------ ------- ----------------------------
Lease Time MAY MUST
Server Identifier MUST (if MUST
multicast)
Lease Identifier MUST MUST
Multicast Scope MUST MUST
Option Request List MUST NOT MUST NOT
Start Time MAY MAY
Number of Addresses
Requested MAY MUST NOT
Requested Language MUST NOT MUST NOT
Multicast Scope List MUST NOT MUST NOT
List of Address Ranges MAY MUST
Current Time MAY MAY
Feature List MAY MAY
Retry Time MUST NOT MAY
Minimum Lease Time MAY MUST NOT
Maximum Start Time MAY MUST NOT
Error MUST NOT MUST NOT
Option RENEW ACK (in response to RENEW)
------ ----- --------------------------
Lease Time MAY MUST
Server Identifier MUST NOT MUST
Lease Identifier MUST MUST
Multicast Scope MUST NOT MUST
Option Request List MUST NOT MUST NOT
Start Time MAY MAY
Number of Addresses
Requested MUST NOT MUST NOT
Requested Language MUST NOT MUST NOT
Multicast Scope List MUST NOT MUST NOT
List of Address Ranges MUST NOT MUST
Current Time MAY MAY
Feature List MAY MAY
Retry Time MUST NOT MAY
Minimum Lease Time MAY MUST NOT
Maximum Start Time MAY MUST NOT
Error MUST NOT MUST NOT
Option RELEASE ACK (in response to RELEASE)
------ ------- ----------------------------
Lease Time MUST NOT MUST NOT
Server Identifier MUST NOT MUST
Lease Identifier MUST MUST
Multicast Scope MUST NOT MUST NOT
Option Request List MUST NOT MUST NOT
Start Time MUST NOT MUST NOT
Number of Addresses
Requested MUST NOT MUST NOT
Requested Language MUST NOT MUST NOT
Multicast Scope List MUST NOT MUST NOT
List of Address Ranges MUST NOT MUST NOT
Current Time MUST NOT MUST NOT
Feature List MAY MAY
Retry Time MUST NOT MUST NOT
Minimum Lease Time MUST NOT MUST NOT
Maximum Start Time MUST NOT MUST NOT
Error MUST NOT MUST NOT
Option NAK
------ ---
Lease Time MUST NOT
Server Identifier MUST
Lease Identifier MUST
Multicast Scope MUST NOT
Option Request List MUST NOT
Start Time MUST NOT
Number of Addresses
Requested MUST NOT
Requested Language MUST NOT
Multicast Scope List MUST NOT
List of Address Ranges MUST NOT
Current Time MUST NOT
Feature List MAY
Retry Time MUST NOT
Minimum Lease Time MUST NOT
Maximum Start Time MUST NOT
Error MUST
Table 5: Options allowed in MADCAP messages
表5：MADCAPメッセージで許可されるオプション
The End option marks the end of valid information in the options field. This option MUST be included at the end of the options field in each MADCAP message.
終了オプションは、オプションフィールドに有効な情報の終わりを示します。このオプションは、各MADCAPメッセージのオプションフィールドの末尾に含まれなければなりません。
The code for this option is 0, and its length is 0.
このオプションのコードは0で、その長さは0です。
Code Len
+-----+-----+-----+-----+
| 0 | 0 |
+-----+-----+-----+-----+
This option is used in a client request (DISCOVER, REQUEST, or RENEW) to allow the client to request a lease time for the multicast address. In a server reply (OFFER or ACK), a MADCAP server uses this option to specify the lease time it is willing to offer.
このオプションは、クライアントがマルチキャストアドレスのリース時間を要求できるようにするために、クライアントの要求（DISCOVER、REQUEST、またはRENEW）で使用されています。サーバの応答（OFFERまたはACK）では、MADCAPサーバは、提供して喜んでリース時間を指定するには、このオプションを使用しています。
The time is in units of seconds, and is specified as a 32-bit unsigned integer.
時間は秒単位であり、32ビットの符号なし整数として指定されています。
The code for this option is 1, and its length is 4.
このオプションのためのコードは1であり、その長さは4です。
Code Len Lease Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
This option contains the IP address of a MADCAP server. A two octet address family number (as defined by IANA, including those defined in [10]) is stored first, followed by the address. The address family for this address is not determined by the addrfamily field in the fixed header so that addresses from one family may be allocated while communicating with a server via addresses of another family.
このオプションでは、MADCAPサーバーのIPアドレスが含まれています。 2つのオクテットのアドレスファミリー番号（[10]で定義されたものを含めて、IANAによって定義されるような）アドレスが続く、最初に格納されています。他のファミリーのアドレスを介してサーバと通信しながら一つの家族からのアドレスが割り当てられてもよいように、このアドレスのアドレスファミリは、固定ヘッダ内addrfamilyフィールドによって決定されません。
All messages sent by a MADCAP server MUST include a Server Identifier option with the IP address of the server sending the message.
MADCAPサーバーから送信されたすべてのメッセージは、メッセージを送信するサーバのIPアドレスを持つサーバ識別子オプションを含まなければなりません。
MADCAP clients MUST include a Server Identifier option in multicast REQUEST messages in order to indicate which OFFER message has been accepted.
MADCAPクライアントが受け入れられたOFFERメッセージを示すために、マルチキャストREQUESTメッセージでサーバ識別子オプションを含まなければなりません。
The code for this option is 2, and its minimum length is 3.
このオプションのためのコードは2であり、その最小の長さは3です。
Code Len Address Family Address
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 2 | n | family | a1 | ... |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
This option is used by MADCAP clients to specify a unique lease identifier. For more information about this option and how it is used, see section 2.4.
このオプションは、ユニークなリース識別子を指定するためにMADCAPクライアントによって使用されます。このオプションとどのようにそれを使用する方法の詳細については、セクション2.4を参照してください。
The code for this option is 3, and its minimum length is 1.
このオプションのためのコードは3であり、その最小の長さは1です。
Code Len Lease Identifier
+-----+-----+-----+-----+-----+-----+---
| 3 | n | i1 | i2 | ...
+-----+-----+-----+-----+-----+-----+---
The multicast scope option is used by the client to indicate the requested multicast scope in a DISCOVER or REQUEST message. It is also used by the MADCAP server to indicate the scope of an assigned address.
マルチキャストスコープオプションは、DISCOVERかREQUESTメッセージで要求されたマルチキャストスコープを示すために、クライアントによって使用されます。また、割り当てられたアドレスの範囲を示すために、MADCAPサーバによって使用されます。
The client may obtain the scope list through the Multicast Scope List option or using some other means. The Scope ID is the first multicast address in the scope. The address family of the Scope ID is determined by the addrfamily field in the fixed header.
クライアントは、マルチキャストスコープの一覧オプションを使用してスコープの一覧を取得したり、他のいくつかの手段を用いても。スコープIDは、範囲の最初のマルチキャストアドレスです。スコープIDのアドレスファミリは、固定ヘッダ内addrfamilyフィールドによって決定されます。
The code for this option is 4, and its minimum length is 1.
このオプションのためのコードは4であり、その最小の長さは1です。
Code Len Scope ID
+-----+-----+-----+-----+-----+-----
| 4 | n | i1 | ...
+-----+-----+-----+-----+-----+-----
This option is used by a MADCAP client in an GETINFO message to request that certain options be included in the server's ACK response. The server SHOULD try to include the specified options in its response, but is not required to do so.
このオプションは、一部のオプションは、サーバーのACK応答に含まれることを要求するGETINFOメッセージでMADCAPクライアントによって使用されます。サーバは、その応答で指定されたオプションが含まれるようにしようとするはずですが、そうする必要はありません。
The format of this option is a list of option codes.
このオプションの形式は、オプションコードのリストです。
The code for this option is 5 and the minimum length is 2.
このオプションのためのコードは5であり、最小の長さは2です。
Code Len Requested Options
+-----+-----+-----+-----+-----+-----+---...
| 5 | n | Option1 |
+-----+-----+-----+-----+-----+-----+---...
The Start Time option specifies the starting time for a multicast address lease.
開始時間のオプションは、マルチキャストアドレスのリースの開始時間を指定します。
A client may include this option in a DISCOVER, RENEW, or REQUEST message to request a multicast address for use at a future time. A server may include this option in an OFFER message or in an ACK in response to REQUEST or RENEW message to indicate that a lease has been granted which starts at a future time.
クライアントは、DISCOVERでこのオプションを含めるRENEW、またはREQUESTメッセージは、将来の時点での使用のためのマルチキャストアドレスを要求することがあります。サーバーは、要求に応じてOFFERメッセージまたはACKでこのオプションを含めるか、またはリースは将来の時点で開始する許可されていることを示すためにメッセージを更新することができます。
If the Start Time option is present, the IP Address Lease Time option specifies the duration of the lease beginning at the Start Time option value.
開始時間のオプションが存在する場合、IPアドレスのリース期間オプションは、開始時間のオプションの値から始まるリース期間を指定します。
If the Start Time option is present, the Current Time option MUST also be present, as described in section 2.12.
開始時間のオプションが存在する場合は2.12節で説明したように、現在時刻のオプションも、存在しなければなりません。
The time value is an unsigned 32 bit integer in network byte order giving the number of seconds since 00:00 UTC, 1st January 1970. This can be converted to an NTP timestamp by adding decimal 2208988800. This time format will not wrap until the year 2106.
時間値00:00 UTCからの秒数を与えるネットワークバイト順で符号なし32ビット整数で、1月1日1970これは小数点2208988800.を追加することにより、NTPタイムスタンプに変換することができますが、この時間形式は年まで折り返されません2106。
The code for this option is 6 and the length is 4.
このオプションのためのコードは6であり、長さが4です。
Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 6 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
This option specifies the minimum and desired number of addresses requested by the client. It is only used in DISCOVER and REQUEST messages and is only sent by the client.
このオプションは、クライアントから要求されたアドレスの最小値と希望数を指定します。それだけでDISCOVERとREQUESTメッセージで使用されており、唯一のクライアントによって送信されます。
The minimum and desired number of addresses requested are unsigned 16 bit integers in network byte order. The minimum MUST be less than or equal to the desired number. If a message is received where this is not the case, the MADCAP server MUST generate and process an Invalid Request error in the manner described in section 2.6.
要求されたアドレスの最小値と所望の数は、ネットワークバイト順に符号なし16ビット整数です。最小値は、所望の数より小さいか等しくなければなりません。そうでない場合、メッセージが受信された場合、MADCAPサーバは、セクション2.6に記載の方法で無効なリクエストエラーを生成して処理しなければなりません。
The client MAY obtain more than one address either by repeating the protocol for every address or by requesting several addresses at the same time via this option. When the client is requesting only one address, this option SHOULD NOT be included. A MADCAP server receiving a DISCOVER or REQUEST packet including this option MUST include between the minimum and desired number of addresses in any OFFER or ACK response.
クライアントは、すべてのアドレスのためのプロトコルを繰り返すことによって、またはこのオプションを使って、同時に複数のアドレスを要求することにより、いずれか一つ以上のアドレスを取得することができます。クライアントは1つのアドレスだけを要求している場合は、このオプションを含めるべきではありません。このオプションを含むDISCOVERまたはREQUESTパケットを受信MADCAPサーバが最小と任意OFFERまたはACK応答のアドレスの所望の数との間に含まなければなりません。
The code for this option is 7 and the length is 4.
このオプションのためのコードは7であり、長さが4です。
Code Len Minimum Desired
+-----+-----+-----+-----+-----+-----+-----+-----+
| 7 | 4 | min | desired |
+-----+-----+-----+-----+-----+-----+-----+-----+
This option specifies the language in which the MADCAP client would like strings such as zone names to be returned. It is only included in an GETINFO message sent by the client. It is an RFC 1766 [6] language tag. The proper way to handle this tag with respect to zone names is discussed further in the definition of the Multicast Scope List option.
このオプションはMADCAPクライアントは、このようなゾーン名などの文字列が返されることを希望する言語を指定します。これは、唯一のクライアントから送信されたGETINFOメッセージに含まれています。これは、RFC 1766 [6]言語タグです。ゾーン名に対するこのタグを処理するための適切な方法は、マルチキャストスコープの一覧オプションの定義でさらに議論されています。
The code for this option is 8 and the minimum length is 0.
このオプションのためのコードは8であり、最小の長さは0です。
Code Len Language Tag
+-----+-----+-----+-----+-----+-...-+-----+
| 8 | n | L1 | | Ln |
+-----+-----+-----+-----+-----+-...-+-----+
This option is sent by the server in an ACK message in response to an GETINFO message sent by the client.
このオプションは、クライアントから送信されたGETINFOメッセージに応答してACKメッセージにサーバーによって送信されます。
If the client did not include a Requested Language option in its GETINFO message, the MADCAP server SHOULD return all zone names for each zone. If the client included a Requested Language option in its GETINFO message, the MADCAP server MUST return no more than one zone name for each zone. For each zone, the MADCAP server SHOULD first look for a zone name that matches the requested language tag (using a case-insensitive ASCII comparison). If any names match, one of them should be returned. Otherwise, the MADCAP server SHOULD choose another zone name to return (if any are defined). It SHOULD give preference to zone names that are marked to be used if no name is available in a desired language.
クライアントがGETINFOメッセージで要求された言語のオプションが含まれていなかった場合は、MADCAPサーバは、各ゾーンのすべてのゾーン名を返すべきです。クライアントがGETINFOメッセージで要求された言語のオプションが含まれている場合、MADCAPサーバーは、ゾーンごとに1つ以下のゾーン名を返してはなりません。各ゾーンについて、MADCAPサーバは、最初の（大文字小文字を区別しないASCII比較を使用して）要求された言語タグと一致するゾーン名を探す必要があります。任意の名前が一致した場合、それらのいずれかが返されます。それ以外の場合は、MADCAPサーバは、（いずれかが定義されている場合）を返すために別のゾーン名を選択する必要があります。それは何の名前が希望の言語で提供されていない場合に使用されるようにマークされているゾーン名を優先させてください。
The code for this option is 9 and the minimum length is 0.
このオプションのためのコードは9であり、最小の長さは0です。
The format of the multicast scope list option is:
マルチキャストスコープリストオプションの形式は次のとおりです。
Code Len Count Scope List
+-----+-----+-----+-----+-----+-----+-...-+-----+
| 9 | p | m | L1 | | Lm |
+-----+-----+-----+-----+-----+-----+-...-+-----+
The scope list is a list of m tuples, where each tuple is of the form:
スコープリストは、各タプルの形式である場合、m個のタプルのリストです。
Scope ID Last Address TTL Name Encoded Name List
Count
+---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+
| ... ID ... | ... Last ... | T | n | EN1 | | ENn |
+---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+
where Scope ID is the first multicast address in the scope, Last Address is the last multicast address in the scope, TTL is the multicast TTL value for the multicast addresses of the scope, and Name Count is the number of encoded names for this zone (which may be zero). The address family of the Scope ID and Last Address is determined by the addrfamily field in the fixed header. Note that a particular MADCAP server may be allocating addresses out of some subset of the scope. For instance, the addresses in the scope may be divided among several servers in some way.
スコープIDは、スコープの最初のマルチキャストアドレスである場合、（最後のアドレスは、範囲内の最後のマルチキャストアドレスは、TTLは、スコープのマルチキャストアドレスのマルチキャストTTL値であり、そして名前Countは、このゾーンのエンコードされた名前の数ですこれはゼロであってもよいです）。スコープIDと最終アドレスのアドレスファミリは、固定ヘッダにaddrfamilyフィールドによって決定されます。特定のMADCAPサーバはスコープのサブセットのうちのアドレスを割り当てることができることに留意されたいです。たとえば、スコープ内のアドレスは、いくつかの方法で、複数のサーバに分割することができます。
Each encoded name is of the form
各エンコードされた名前の形式は
Name Lang Language Tag Name Name
Flags Length Length
+-----+-----+-----+-...-+-----+-----+-----+-...-+-----+
| F | q | L1 | | Lq | r | N1 | | Nr |
+-----+-----+-----+-...-+-----+-----+-----+-...-+-----+
where Name Flags is a flags field with flags defined below, Lang Length is the length of the Language Tag in octets (which MUST NOT be zero), Language Tag is a language tag indicating the language of the zone name (as described in [6]), Name Length is the length of the Name in octets (which MUST NOT be zero), and Name is a UTF-8 [5] string indicating the name given to the scope zone.
以下に定義されるフラグでフラグフィールド場所名フラグである、ラングの長さは（ゼロでないこと）オクテットで言語タグの長さであり、言語のタグに記載されているように（ゾーン名の言語を示す言語タグである[6 ]）、名の長さがゼロであるはずがありませんオクテット（）内の名前の長さであり、名前はスコープゾーンに与えられた名前を表すUTF-8 [5]の文字列です。
The high bit of the Name Flags field is set if the following name should be used if no name is available in a desired language. Otherwise, this bit is cleared. All remaining bits in the octet SHOULD be set to zero and MUST be ignored.
何の名前が希望の言語で提供されていない場合は、次の名前を使用する必要がある場合は、[名前のフラグフィールドの高ビットが設定されています。それ以外の場合、このビットはクリアされます。オクテット内のすべての残りのビットはゼロに設定されるべきであり、無視しなければなりません。
The Scope IDs of entries in the list MUST be unique and the scopes SHOULD be listed from smallest (topologically speaking) to largest. This makes it easier to display a consistent user interface, with scopes usually keeping the same order. However, scopes may not be strictly nested. In this circumstance, there is no strict ordering from smallest to largest and the server must use another technique for ordering the scope list.
最大のリストのエントリのスコープIDは一意である必要があり、スコープは、最小（位相幾何学的に言えば）から表示される必要があります。これは、それが簡単にスコープは通常、同じ順番を保ちながら、一貫性のあるユーザー・インターフェースを表示することが可能となります。ただし、スコープは厳密に入れ子にすることはできません。この状況では、最小から最大とサーバはスコープのリストを注文するための別の技術を使用する必要がありますに厳密な順序はありません。
Example:
例：
There are two scopes supported by the multicast address allocation server: Inside abcd.com with addresses 239.192.0.0-239.195.255.255, and world with addresses 224.0.1.0-238.255.255.255. Then this option will be given as:
abcd.com内部アドレス239.192.0.0-239.195.255.255、そして世界とのアドレス224.0.1.0-238.255.255.255と：マルチキャストアドレス割り当てサーバでサポートされている2つのスコープがあります。このオプションは、次のように与えられます。
Code Len Count
+-----+-----+-----+-----+-----+...
| 9 | 51 | 2 |
+-----+-----+-----+-----+-----+...
Scope ID Last Address TTL Name Name Lang Language
Count Flags Length Tag
+---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
|239|192| 0 | 0 |239|195|255|255|10 | 1 | 128 | 2 | en |
+---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
Name
Length Name
+------+--+--+-...-+--+--+...
| 15 | Inside abcd.com |
+------+--+--+-...-+--+--+...
Scope ID Last Address TTL Name Name Lang Language
Count Flags Length Tag
+---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
|224| 0 | 1 | 0 |238|255|255|255|16 | 1 | 128 | 2 | en |
+---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
Name
Length Name
+------+--...--+
| 5 | world |
+------+--...--+
This option is used by the server to provide the list of all the address ranges allocated to the client.
このオプションは、クライアントに割り当てられたすべてのアドレス範囲のリストを提供するために、サーバーによって使用されます。
This option is also used by the client when requesting a lease for a specific set of addresses. This feature should be needed only rarely, such as when a lease is accidentally allowed to expire and it needs to be reallocated.
アドレスの特定のセットのためのリースを要求する場合、このオプションは、クライアントによって使用されます。この機能は、リースが誤って期限切れにさせ、それを再割り当てする必要があるときなど、まれにしか必要としません。
The address family of the addresses is determined by the addrfamily field.
アドレスのアドレスファミリはaddrfamilyフィールドによって決定されます。
The code for this option is 10 and the minimum length is 0.
このオプションのためのコードは10であり、そして最小の長さは0です。
Code Len Address Range List
+-----+-----+-----+-----+-----+-----+-...-+-----+
| 10 | n | L1 | L2 | | Ln |
+-----+-----+-----+-----+-----+-----+-...-+-----+
where the Address Range List is of the following format.
アドレス範囲のリストは、次の形式のです。
StartAddress1 BlockSize1 StartAddress2 BlockSize2 ...
+---+---+---+---+---+---+---+---+---+---+---+---+--...--+
| ... S1 ... |B11|B12| ... S2 ... |B21|B22| |
+---+---+---+---+---+---+---+---+---+---+---+---+--...--+
This option is used to express what the sender thinks the current time is. This is useful for detecting clock skew. This option MUST be included if the Start Time or Maximum Start Time options are used, as described in section 2.12.
このオプションは、送信者は、現在の時刻がどう思うか表現するために使用されています。これは、クロック・スキューを検出するために有用です。開始時間または最大開始時間のオプションが使用されている場合は2.12節で説明したように、このオプションは、含まれなければなりません。
The time value is an unsigned 32 bit integer in network byte order giving the number of seconds since 00:00 UTC, 1st January 1970. This can be converted to an NTP [4] timestamp by adding decimal 2208988800. This time format will not wrap until the year 2106.
時間値はラップしないであろう小数2208988800.この時間形式を追加することにより、1月1日1970年これは、NTP [4]タイムスタンプに変換することができる午前0時UTCからの秒数を与えるネットワークバイト順に符号なし32ビット整数です。年間2106まで。
The code for this option is 11 and the length is 4.
このオプションのためのコードは11であり、長さが4です。
Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 11 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
This option lists optional MADCAP features supported, requested, or required, by the sender. This option MAY be included in any message sent by a MADCAP server or client.
このオプションリストオプションMADCAPは、サポート要求、または送信者によって、必要な機能します。このオプションはMADCAPサーバーまたはクライアントから送信されたメッセージに含まれるかもしれません。
Optional features of MADCAP are identified with a two octet feature code. New MADCAP feature codes may only be defined by IETF Consensus, as described in section 5.
MADCAPのオプション機能は、2つのオクテットの機能コードで識別されています。セクション5に記載されているように新しいMADCAP機能コードのみ、IETF合意によって定義されてもよいです。
The Feature List option consists of three separate lists: supported features, requested features, and required features. Each list consists of an unordered list of feature codes. The supported list is used by MADCAP clients or servers to indicate the features that the sender supports. The requested and required lists are used by MADCAP clients to indicate which features are requested of or required from a MADCAP server. The required list is used by MADCAP servers to indicate which features were implemented by the MADCAP server in processing this message. Messages sent by MADCAP servers MUST NOT include any feature codes in the requested list.
サポートされている機能、要求された機能、および必要な機能：機能一覧オプションは、3つの別々のリストで構成されています。各リストは、機能コードの順不同のリストで構成されます。サポートリストには、送信者がサポートする機能を示すために、MADCAPクライアントまたはサーバによって使用されます。要求され、必要なリストは、要求されたのか、MADCAPサーバーから必要とされる機能を示すために、MADCAPクライアントによって使用されています。必要なリストは、このメッセージを処理するにはMADCAPサーバによって実装された機能を示すために、MADCAPサーバによって使用されます。 MADCAPサーバによって送信されたメッセージは、要求されたリスト内の任意の特徴コードを含んではいけません。
If a MADCAP client includes the Feature List option in a message, it MAY include features in any of the lists: supported, requested, and required. If a MADCAP server receives a message containing the Feature List option and it does not support all of the features in the required list, it MUST generate and process a Required Feature Not Supported error in the manner described in section 2.6. If the server supports all of the features in the required list, it MUST implement them as appropriate for this message. It SHOULD try to implement the features in the requested list and it MAY implement any of the features in the supported list. If an optional feature (such as Retry After) is not included in any part of the Feature List option included in the client's message (or if the client does not include a Feature List option in its message), the server MUST NOT use that feature in its response.
MADCAPクライアントがメッセージで機能リストオプションが含まれている場合、それはリストのいずれかの特徴を含むことができる：、サポート要求、および必要。 MADCAPサーバーは、機能リストのオプションを含むメッセージを受信し、それが必要なリスト内のすべての機能をサポートしていない、それは必要なを生成し、処理しなければならない場合はセクション2.6に記載された方法でサポートされていないエラーが備わっています。サーバが必要なリストにあるすべての機能をサポートしている場合、それは、このメッセージに応じてそれらを実装しなければなりません。これは、要求されたリスト内の機能を実装しようとする必要があり、それがサポートされ、リスト内の機能のいずれかを実施することができます。 （例えば後に再試行など）のオプション機能は、クライアントのメッセージに含まれる機能一覧のオプションのいずれかの部分に含まれていない場合は、サーバがその機能を使用してはならない（またはクライアントがそのメッセージに機能リストのオプションが含まれていない場合）その応答インチ
If a MADCAP server does respond to a client's message that includes a Feature List option, the server MUST include a Feature List option with a supported features list that lists the features that it supports, a required features list that lists the features that it implemented in responding to this message (which must be included in the supported features list of the client's Feature List option), and an empty requested features list.
MADCAPサーバーは、機能リストのオプションが含まれ、クライアントのメッセージに応答しなければ、サーバはそれがサポートする機能を示していますサポートされている機能の一覧と機能一覧オプション、それがで実装された機能をリストし、必要な機能のリストを含まなければなりません（クライアントの機能一覧オプションのサポートされている機能のリストに含まれなければならない）、このメッセージ、および空要求された機能のリストへの対応。
The code for this option is 12 and the minimum length is 6.
このオプションのためのコードは12であり、そして最小の長さは6です。
Code Len Supported Requested Required
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 12 | n | FL1 | FL2 | FL3 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
where each of the Feature Lists is of the following format:
フィーチャーリストのそれぞれは、次の形式である場合：
Feature Feature Feature
Count Code 1 Code m
+-----+-----+-----+-----+-...-+-----+-----+
| m | FC1 | | FCm |
+-----+-----+-----+-----+-...-+-----+-----+
The Retry Time option specifies the time at which a client should retry a REQUEST or RENEW message when using the Retry After feature.
再試行時間オプションは、クライアントが要求を再試行するか、機能した後の再試行を使用している場合、メッセージをRENEWする時刻を指定します。
This option should only be sent by a MADCAP server in an ACK when responding to a REQUEST or RENEW message that includes the Retry After feature in the supported, requested, or required list. For more discussion of Retry After, see section 2.13.2.
このオプションは、要求に応答するとき、ACKでMADCAPサーバによって送信されたか、サポート要求、または必要なリストで機能した後の再試行を含むメッセージをRENEWする必要があります。後に再試行のより多くの議論については、セクション2.13.2を参照してください。
If the Retry Time option is present, the Current Time option MUST also be present.
再試行Timeオプションが存在する場合、現在の時刻オプションも存在しなければなりません。
The time value is an unsigned 32 bit integer in network byte order giving the number of seconds since 00:00 UTC, 1st January 1970. This can be converted to an NTP timestamp by adding decimal 2208988800. This time format will not wrap until the year 2106.
時間値00:00 UTCからの秒数を与えるネットワークバイト順で符号なし32ビット整数で、1月1日1970これは小数点2208988800.を追加することにより、NTPタイムスタンプに変換することができますが、この時間形式は年まで折り返されません2106。
The code for this option is 13 and the length is 4.
このオプションのためのコードは13であり、長さが4です。
Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 13 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
This option is used in a client request (DISCOVER, REQUEST, or RENEW) to allow the client to specify a minimum lease time for the multicast address. If a server cannot meet this minimum lease time, it MUST generate and process a Valid Request Could Not Be Completed error in the manner described in section 2.6.
このオプションは、クライアントがマルチキャストアドレスの最小リース時間を指定することができるように、クライアント要求（DISCOVER、REQUEST、またはRENEW）で使用されています。サーバはこの最小リース時間を満たすことができない場合は、それが生成し、有効な要求は、セクション2.6に記載された方法でエラーを完了できませんでし処理しなければなりません。
The time is in units of seconds, and is specified as a 32-bit unsigned integer.
時間は秒単位であり、32ビットの符号なし整数として指定されています。
The code for this option is 14, and its length is 4.
このオプションのためのコードは14であり、その長さは4です。
Code Len Lease Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 14 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
The Maximum Start Time option specifies the latest starting time that the client is willing to accept for a multicast address lease.
最大開始時間オプションは、クライアントがマルチキャストアドレスのリースのために受け入れることを望んで最新の開始時間を指定します。
A client may include this option in a DISCOVER, RENEW, or REQUEST message to specify that it does not want to receive a lease with a starting time later than the specified value. If a server cannot meet this maximum start time, it MUST generate and process a Valid Request Could Not Be Completed error in the manner described in section 2.6.
クライアントは、DISCOVERでこのオプションを含めるRENEW、またはREQUESTメッセージは、指定した値よりも後の開始時間とのリースを受信したくないことを指定することがあります。サーバーがこの最大開始時間を満たすことができない場合は、それが生成し、有効な要求は、セクション2.6に記載された方法でエラーを完了できませんでし処理しなければなりません。
If the Maximum Start Time option is present, the Current Time option MUST also be present, as described in section 2.12.
最大開始時間のオプションが存在する場合は2.12節で説明したように、現在時刻のオプションも、存在しなければなりません。
The time value is an unsigned 32 bit integer in network byte order giving the number of seconds since 00:00 UTC, 1st January 1970. This can be converted to an NTP timestamp by adding decimal 2208988800. This time format will not wrap until the year 2106.
時間値00:00 UTCからの秒数を与えるネットワークバイト順で符号なし32ビット整数で、1月1日1970これは小数点2208988800.を追加することにより、NTPタイムスタンプに変換することができますが、この時間形式は年まで折り返されません2106。
The code for this option is 15 and the length is 4.
このオプションのためのコードは15であり、長さが4です。
Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 15 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
A MADCAP server includes this option in a NAK message to indicate why the request failed. A MADCAP server MUST include an Error option in each NAK message.
MADCAPサーバーは、要求が失敗した理由を示すために、NAKメッセージにこのオプションが含まれています。 MADCAPサーバは、各NAKメッセージのエラーオプションを含まなければなりません。
The first two octets of an Error option contain a MADCAP error code. Several MADCAP error codes are defined later in this section. New MADCAP error codes may only be defined by IETF Consensus, as described in section 5.
Errorオプションの最初の2つのオクテットはMADCAPエラーコードが含まれています。いくつかのMADCAPエラーコードは、このセクションの後半で定義されています。セクション5に記載されているように新しいMADCAPエラーコードのみ、IETF合意によって定義されてもよいです。
Any remaining octets in the Error option contain extra data about the error. The format of this data depends on the error code. The definition of a MADCAP error code must include a definition of the extra data to be included with that error code.
Errorオプションで残りのオクテットは、エラーに関する追加データが含まれています。このデータの形式は、エラーコードに依存します。 MADCAPエラーコードの定義は、余分なデータの定義は、そのエラーコードに含まれていることが含まれている必要があります。
A client that receives a NAK message containing an Error option MAY log or display a message indicating the error code and extra data received. The client MUST NOT retransmit a message once a NAK response to that message has been received. The client MAY adjust the message to correct the error and send the corrected message or send a message to a different server.
ログインするか、受信したエラーコードと、余分なデータを示すメッセージが表示されるエラーオプションを含むNAKメッセージを受信したクライアント。クライアントは、一度そのメッセージにNAK応答を受信したメッセージを再送してはなりません。クライアントは、エラーを修正し、修正したメッセージを送信したり、別のサーバーにメッセージを送信するメッセージを調整することができます。
The code for this option is 16, and the minimum length is 2.
このオプションのためのコードは16であり、そして最小の長さは2です。
Code Len Error Code Extra Data
+-----+-----+-----+-----+-----+-----+-----+-----+ ...
| 16 | n | ecode | d1 d2
+-----+-----+-----+-----+-----+-----+-----+-----+ ...
MADCAP error code 0 indicates that the request was valid, but could not be completed with the available addresses and the current configuration. The extra data is a two octet option code indicating which option caused the problem. A value of 0xFFFF indicates that the problem was not with a specific option.
MADCAPエラーコード0要求が有効であったことを示しているが、利用可能なアドレスと現在の構成で完了することができませんでした。余分なデータは、問題の原因となったオプションを示す2つのオクテットオプションコードです。値0xFFFFは、問題が特定のオプションを使用していなかったことを示しています。
MADCAP error code 1 indicates that the request was malformed or invalid in some other manner. The extra data is a two octet option code indicating which option caused the problem. A value of 0xFFFF indicates that the problem was not with a specific option.
MADCAPエラーコード1は、要求が他の方法で不正な、または無効であったことを示しています。余分なデータは、問題の原因となったオプションを示す2つのオクテットオプションコードです。値0xFFFFは、問題が特定のオプションを使用していなかったことを示しています。
MADCAP error code 2 indicates excessive clock skew (see section 2.12). The extra data consists of a four octet time value representing the server's idea of the current time, an unsigned 32 bit integer in network byte order giving the number of seconds since 00:00 UTC, 1st January 1970. This can be converted to an NTP timestamp by adding decimal 2208988800. This time format will not wrap until the year 2106.
MADCAPエラーコード2（セクション2.12を参照）、過剰なクロック・スキューを示します。余分なデータは、現在の時刻のサーバーの考え方、午後12時（UTC）からの秒数を与えるネットワークバイト順で符号なし32ビット整数を表す4つのオクテット時間値で構成され、1月1日1970これは、NTPに変換することができます小数2208988800.この時刻の形式を追加することにより、タイムスタンプは、今年2106年まで折り返されません。
MADCAP error code 3 indicates that the Lease Identifier was not recognized (usually in response to a RENEW or RELEASE message). There is no extra data.
MADCAPエラーコード3がリース識別子（通常RENEWまたはRELEASEメッセージに応答して）認識されなかったことを示しています。余分なデータがありません。
MADCAP error code 4 indicates that at least one feature included in the required list of the Feature List option is not supported. The extra data contains a list of the feature codes in the required list that are not supported.
MADCAPエラーコード4は、少なくとも1つの特徴がサポートされていない機能一覧オプションの必要なリストに含まれていることを示しています。余分なデータがサポートされていない必要なリスト内の特徴コードのリストが含まれています。
MADCAP error codes 1024-2047 are reserved for experimental use. The format of the extra data included with these error codes is not defined.
MADCAPエラーコード1024から2047までは、実験的な使用のために予約されています。これらのエラーコードに含まれる余分なデータのフォーマットが定義されていません。
MADCAP has relatively basic security requirements. At present there is no way of enforcing authorized use of multicast addresses in the multicast routing/management protocols. Therefore, it is not possible to identify unauthorized use of multicast address by an adversary. Moreover, a multicast address allocated to a user/system can be used by other systems without violating terms of the multicast address allocation. For example, a system may reserve an address to be used for a work group session where each and every member of the work group is allowed to transmit packets using the allocated group address. In other words, the multicast address allocation protocol does not dictate how the address should be used, it only dictates the time period for which it can be used and who gets to release it or renew it. When an address is allocated to a system/user, it basically means that no other user/system (most likely) will be allocated that address for the time period, without any restrictions on its use.
MADCAPは、比較的基本的なセキュリティ要件があります。現時点では、マルチキャストルーティング/管理プロトコルにおけるマルチキャストアドレスの許可使用を強制する方法はありません。したがって、敵対者によるマルチキャストアドレスの不正使用を特定することは不可能です。また、ユーザ/システムに割り当てられたマルチキャストアドレスがマルチキャストアドレス割り当ての規約に違反することなく、他のシステムで使用することができます。例えば、システムは、作業グループの各々及びすべてのメンバーは、割り当てられたグループアドレスを使用してパケットを送信するために許可されているワークグループセッションのために使用されるアドレスを予約することができます。言い換えれば、マルチキャストアドレス割り当てプロトコルは、アドレスが使用されるべき方法を指示しない、それだけで、それを使用できる期間を指示し、誰がそれを解放するかを更新する取得します。アドレスはシステム/ユーザーに割り当てられている場合、それは基本的に他のユーザ/システム（最も可能性が高い）ことを意味し、その使用に制限せずに、時間だけそのアドレスを割り当てられます。
To protect against rogue MADCAP servers (mis-configured servers and intentional), clients in certain situations would like to authenticate the server. Similarly, for auditing or book-keeping purposes, the server may want to authenticate clients. Moreover, in some cases, the server may have certain policies in place to restrict the number of addresses that are allocated to a system or a user. This feature is of much value when a well behaved but naive user or client requests a large number of addresses, and therefore, inadvertently impacts other users or systems. Therefore, an administrator may want to exert a limited amount of control based on the client identification. The client identification could be based on the system or user identity. In most practical situations, system identification will suffice, however, particularly in case of multi-user systems, at times, user identification will play an important role. Therefore, authentication capabilities based on user identification may be desirable. As usual, data integrity is a strong requirement and if not protected, can lead to many problems including denial of service attacks.
不正なMADCAPサーバ（誤設定されたサーバや意図的な）から保護するために、特定の状況でクライアントがサーバを認証したいと思います。同様に、監査や簿記の目的のために、サーバがクライアントを認証することもできます。また、いくつかのケースでは、サーバは、システムまたはユーザに割り当てられているアドレスの数を制限する代わりに、特定のポリシーを有することができます。この機能は、行儀が、ナイーブユーザーやクライアントが多数のアドレスを要求したときに非常に価値があり、そのため、不用意に影響を与える他のユーザーまたはシステム。そのため、管理者がクライアントの識別に基づいて制御の限られた量を発揮することができます。クライアントの識別は、システムまたはユーザーのアイデンティティに基づくことができます。最も実用的な状況では、システム識別は、十分ですが、特にマルチユーザシステムの場合には、時々、ユーザ識別は重要な役割を果たします。このため、ユーザ識別に基づいて認証機能が望ましいかもしれません。いつものように、データの整合性が強く要求され、保護されていない場合は、サービス拒否攻撃など、多くの問題につながることができます。
In the case of MADCAP, confidentiality is not a strong requirement. In most of the cases, at least when a multicast address is in use, an adversary will be able to determine information that was contained in the MADCAP messages. In some cases, the users/systems may want to protect information in the MADCAP messages so that an adversary is not able to determine relevant information in advance and thus, plan an attack in advance. For example, if an adversary knows in advance (based on MADCAP messages) that a particular user has requested a large number of address for certain time period and scope, he may be able to guess the purpose behind such request and target an attack. When the Shared Lease Identifier feature is used, preserving the confidentiality of MADCAP messages becomes more important. Also, there may be features added to the protocol in the future that may have stronger confidentiality requirements.
MADCAPの場合は、機密性が強い要件ではありません。ほとんどの場合、マルチキャストアドレスが使用中である少なくとも場合、敵対者はMADCAPメッセージに含まれていた情報を決定することができるであろう。いくつかのケースでは、ユーザ/システムは、敵対者が事前に関連する情報を決定するため、事前に攻撃を計画することができないように、MADCAPメッセージ内の情報を保護することをお勧めします。例えば、敵が事前に知っていれば（MADCAPメッセージに基づいて）特定のユーザが特定の期間と範囲のアドレスを大量に要求したことを、彼はそのような要求の後ろに目的を推測し、攻撃を標的にすることができるかもしれません。共有リース識別子機能を使用すると、MADCAPメッセージの機密性を維持することはより重要になります。また、強力な機密性の要件がある場合があり、将来的にプロトコルに追加された機能があるかもしれません。
The IPSEC protocol [8] meets client/server identification and integrity protection requirements stated above, requires no modification to the MADCAP protocol, and leverages extensive work in IETF and industry. Therefore, when security is a strong requirement, IPSEC SHOULD be used for protecting all the unicast messages of MADCAP protocol. When IPSEC based security is in use, all the multicast packets except GETINFO MUST be dropped by the MADCAP server. The prevalent implementations of IPSEC support client identification in form of system identification and do not support user identification. However, when desired, IPSEC with appropriate API's may be required to support user identification.
IPSECプロトコル[8]は、上記のクライアント/サーバ識別および完全性保護の要件を満たしているMADCAPプロトコルへの変更を必要とせず、IETFや業界の広範な作業を活用しています。セキュリティが強い要求がある場合したがって、IPSECはMADCAPプロトコルのすべてのユニキャストメッセージを保護するために使用されるべきです。 IPSECベースのセキュリティを使用している場合は、GETINFOを除くすべてのマルチキャストパケットは、MADCAPサーバによって下げなければなりません。システム識別の形でIPSECサポートクライアント識別の流行の実装およびユーザ識別をサポートしていません。但し、所望ならば、適切なAPIの持つIPSECは、ユーザ識別をサポートするために必要とされ得ます。
This document defines several number spaces (MADCAP options, MADCAP message types, MADCAP Lease Identifier types, MADCAP features, and MADCAP error codes). For all of these number spaces, certain values are defined in this specification. New values may only be defined by IETF Consensus, as described in [7]. Basically, this means that they are defined by RFCs approved by the IESG.
この文書は、いくつかの数のスペース（MADCAPオプション、MADCAPメッセージタイプ、MADCAPリース識別子タイプ、MADCAP機能、およびMADCAPエラーコード）を定義します。これらの番号空間のすべてについて、特定の値は、本明細書で定義されています。 [7]に記載のように新しい値のみ、IETF合意によって定義されてもよいです。基本的に、これは、それらがIESGによって承認されたRFCで定義されていることを意味します。
The authors would like to thank Rajeev Byrisetty, Steve Deering, Peter Ford, Mark Handley, Van Jacobson, David Oran, Thomas Pfenning, Dave Thaler, Ramesh Vyaghrapuri and the participants of the IETF for their assistance with this protocol.
著者は、このプロトコルとその支援のためのRajeev Byrisetty、スティーブデアリング、ピーター・フォード、マーク・ハンドリー、バン・ジェイコブソン、デヴィッドオラン、トーマスPfenning、デーブターラー、ラメシュVyaghrapuriとIETFの参加者に感謝したいと思います。
Much of this document is based on [1] and [2]. The authors of this document would like to express their gratitude to the authors of these previous works. Any errors in this document are solely the fault of the authors of this document.
この文書の多くはに基づいている[1]と[2]。本書の著者は、これらの以前の作品の作者に感謝の意を表したいと思います。このドキュメントに間違いはもっぱらこの文書の著者の障害です。
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[1] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[2]アレクサンダー、S.とR. Droms、 "DHCPオプションとBOOTPベンダー拡張機能"、RFC 2132、1997年3月。
[3] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[3]マイヤー、D.、 "管理用スコープのIPマルチキャスト"、BCP 23、RFC 2365、1998年7月。
[4] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[4]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装と分析"、RFC 1305、1992年3月。
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[5] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 2279、1998年1月。
[6] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[6] Alvestrand、H.、 "言語識別のためのタグ"、RFC 1766、1995年3月。
[7] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[7] Alvestrand、H.、およびT. Narten氏、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[8] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[8]アトキンソン、R.とS.ケント、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[10]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月。
[11] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[11]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[12]デアリング、S.とR. Hindenと "インターネットプロトコル、バージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[13] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[13] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[14] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[14] Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、1996年1月。
Stephen R. Hanna Sun Microsystems, Inc. One Network Drive Burlington, MA 01803
スティーブン・R.ハンナサン・マイクロシステムズ株式会社ワンネットワークドライブバーリントン、MA 01803
Phone: +1.781.442.0166 EMail: steve.hanna@sun.com
電話：+1.781.442.0166電子メール：steve.hanna@sun.com
Baiju V. Patel Intel Corp. Mail Stop: AG2-201 5200 NE Elam Young Parkway Hillsboro, OR 97124
Baiju V.パテルインテル社のメール停止：AG2-201 5200 NEエラムヤングパークウェイヒルズボロ、OR 97124
Phone: 503 696 8192 EMail: baiju.v.patel@intel.com
電話：503 696 8192 Eメール：baiju.v.patel@intel.com
Munil Shah Microsoft Corporation One Microsoft Way Redmond, WA 98052
Munilシャーマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
Phone: 425 703 3924 EMail: munils@microsoft.com
電話：425 703 3924 Eメール：munils@microsoft.com
APPENDIX A: Examples
付録A：例
This appendix includes several examples of typical MADCAP protocol exchanges.
この付録では、典型的MADCAPプロトコル交換のいくつかの例を含みます。
In this example, a MADCAP client wants to determine the scope list in effect. The client is using IPv4, so it starts by multicasting an GETINFO packet to the MADCAP Server Multicast Address corresponding to IPv4 Local Scope. This packet includes the Lease Identifier option, an Option Request List including the Multicast Scope List option code, and a Requested Language option containing the string "en", since the client is configured to prefer the English language.
この例では、MADCAPクライアントは、実際にはスコープのリストを決定したいと考えています。クライアントは、IPv4を使用しているので、IPv4のローカルスコープに対応するMADCAPサーバーのマルチキャストアドレスへGETINFOパケットをマルチキャストすることによって開始されます。クライアントが英語を好むように設定されているので、このパケットは、リース識別子オプション、マルチキャストスコープの一覧オプションコードを含むオプション要求リスト、および文字列「EN」を含む要求された言語のオプションが含まれています。
Two MADCAP servers respond by sending ACK messages. These ACK messages include the Lease Identifier option and xid supplied by the client, the server's Server Identifier, and the Multicast Scope List with one name per scope (the one that most closely matches the language tag "en").
二つのMADCAPサーバは、ACKメッセージを送信することで応答します。これらのACKメッセージは、リース識別子オプションとクライアント、サーバーのサーバー識別子によって提供されるXID、およびスコープごとに1名（最も密接に言語タグ「EN」と一致するもの）とのマルチキャストスコープの一覧が含まれています。
The following figure illustrates this exchange.
次の図は、この交換を示しています。
Server Client Server
v v v
| | |
| | |
| _____________/|\_____________ |
|/ GETINFO | GETINFO \|
| | |
| | |
|\ | ____________/|
| \_________ | / ACK |
| ACK \ |/ |
| \ | |
| | |
v v v
Figure 2: Timeline diagram of messages exchanged in Multicast Scope List Discovery example
図2：メッセージのタイムライン図は、マルチキャストスコープ一覧ディスカバリーの例で交換しました
In this example, the MADCAP client wants to allocate a multicast address from the global scope for use during the next two hours.
この例では、MADCAPクライアントは、次の2時間の間に使用するためにグローバルスコープからマルチキャストアドレスを割り当てることを望んでいます。
The client begins by multicasting a DISCOVER packet to the MADCAP Server Multicast Address associated with IPv4 Local Scope. This packet includes the Lease Time, Lease Identifier, and Multicast Scope options.
クライアントは、IPv4ローカルスコープに関連付けられているMADCAPサーバーのマルチキャストアドレスにDISCOVERパケットをマルチキャストして開始します。このパケットは、リース期間、リース識別子、およびマルチキャストスコープオプションが含まれています。
Any servers that receive the DISCOVER packet and can satisfy this request temporarily reserve an address for the client and unicast an OFFER packet to the client. These packets contain the Lease Time, Server Identifier, Lease Identifier, and Multicast Scope options.
DISCOVERパケットを受信し、この要求を満たすことができる任意のサーバーが一時的にクライアントのアドレスを予約し、クライアントに提供するパケットをユニキャスト。これらのパケットは、リース期間、サーバー識別子、リース識別子、およびマルチキャストスコープオプションが含まれています。
After an appropriate delay, the client multicasts a REQUEST packet to the MADCAP Server Multicast Address. This packet contains all of the options included in the DISCOVER packet, but also includes the Server Identifier option, indicating which server it has selected for the request.
適切な遅延の後、クライアントはMADCAPサーバーのマルチキャストアドレスへの要求パケットをマルチキャスト。このパケットは、DISCOVERパケットに含まれるすべてのオプションが含まれていますが、またそれは要求のために選択したサーバーを示す、サーバ識別子オプションを含んでいます。
The server whose Server Identifier matches the one specified by the client responds with an ACK packet containing the options included in the OFFER packet, as well as a List of Address Ranges option listing the address allocated. All the other servers that had sent OFFER packets stop reserving an address for the client and forget about the whole exchange.
そのサーバー識別子、クライアントによって指定されたものと一致したOFFERパケットに含まれるオプションを含むACKパケットで応答し、サーバだけでなく、アドレスのリストは、割り当てられたアドレスをリストするオプションの範囲です。 OFFERパケットを送っていた他のすべてのサーバーは、クライアントのアドレスを予約停止し、全交流を忘れます。
The client now has a two hour "lease" on the multicast address.
クライアントは、マルチキャストアドレス上の2つの時間「リース」を持っています。
If the client had not received an ACK from the server, it would have retransmitted its REQUEST packet for a while. If it still received no response, it would start over with a new DISCOVER message.
クライアントがサーバからのACKを受け取っていなかった場合、それはしばらくの間、その要求パケットを再送しているだろう。それはまだ応答を受信しない場合は、新しいDISCOVERメッセージをやり直すでしょう。
The following figure illustrates this exchange.
次の図は、この交換を示しています。
Server Client Server
(not selected) (selected)
v v v
| | |
|Begin multicast address request|
| | |
| _____________/|\_____________ |
|/ DISCOVER | DISCOVER \|
| | |
Reserves | Reserves
Address | Address
| | |
|\ | ____________/|
| \_________ | / OFFER |
| OFFER \ |/ |
| \ | |
| Collects replies |
| \| |
| Selects Server |
| | |
| _____________/|\_____________ |
|/ REQUEST | REQUEST \|
| | |
| | Commits address
| | |
| | _____________/|
| |/ ACK |
| | |
| assignment complete |
| | |
v v v
Figure 3: Timeline diagram of messages exchanged in Multicast Address Allocation example
図3：マルチキャストアドレス割り当ての例で交換されるメッセージのタイムライン図
This is a continuation of the previous example. The client has already allocated a multicast address from the global scope for use during the next two hours. Half way through this two hour period, it decides that it wants to extend its lease for another hour.
これは、前の例の続きです。クライアントは、すでに次の2時間の間に使用するためにグローバルスコープからマルチキャストアドレスを割り当てています。この2時間の期間を通じて途中、それは別の時間にそのリースを延長したいと判断しました。
The client unicasts a RENEW packet to the server from which it allocated the address. This packet includes the Lease Time and Lease Identifier options. The Lease Identifier matches the one used for the original allocation. The time included in the Lease Time is two hours, since the client wants the lease to expire two hours from the current time.
クライアントは、それがアドレスを割り当てられ、そこからサーバーにRENEWパケットをユニキャストします。このパケットは、リース期間とリース識別子オプションが含まれています。リース識別子は、元の割り当てのために使用されるものと一致します。クライアントはリースが現在の時刻から2時間を期限切れにしたいので、リース期間に含まれた時間は、2時間です。
The server responds with an ACK packet indicating that the lease extension has been granted. This packet includes the Lease Time, Server Identifier, Lease Identifier, Multicast Scope, and List of Address Ranges options.
サーバは、リースの延長が許可されたことを示すACKパケットで応答します。このパケットは、リース期間、サーバー識別子、リース識別子、マルチキャストスコープを備えており、アドレスの一覧は、オプションの範囲です。
If the server did not want to grant the requested lease extension, it would have responded with a NAK packet with the Lease Identifier option.
サーバは要求されたリースの延長を許可したくなかった場合は、リース識別子オプション付きNAKパケットで応答しているだろう。
The following figure illustrates this exchange.
次の図は、この交換を示しています。
Client Server
v v
| |
|\_____________ |
| RENEW \|
| |
| Extends lease
| |
| _____________/|
|/ ACK |
| |
| |
v v
Figure 4: Timeline diagram of messages exchanged in Lease Extension example
図4：リース延長の例で交換されるメッセージのタイムライン図
This is a continuation of the previous example. The client has already allocated a multicast address and extended its lease for another two hours. Half an hour later, the client finishes its use of the multicast address and wants to release it so it can be reused.
これは、前の例の続きです。クライアントがすでにマルチキャストアドレスを割り当てられ、別の2時間にそのリースを延長しました。時間半後に、クライアントは、マルチキャストアドレスの使用を終了し、それを再利用できるようにそれを解放したいと考えています。
The client unicasts a RELEASE packet to the server from which it allocated the address. This packet includes the Lease Identifier option. The Lease Identifier matches the one used for the original allocation. When the server receives this packet, it cancels the client's lease on the address and sends an ACK packet to the client indicating that the lease has been released. This packet includes the Server Identifier and Lease Identifier options.
クライアントは、それがアドレスを割り当てられたサーバにRELEASEパケットをユニキャストします。このパケットは、リース識別子オプションを含んでいます。リース識別子は、元の割り当てのために使用されるものと一致します。サーバはこのパケットを受信すると、アドレス上のクライアントのリースをキャンセルし、リースが解放されたことを示すクライアントにACKパケットを送信します。このパケットはサーバ識別子とリース識別子オプションが含まれています。
The following figure illustrates this exchange.
次の図は、この交換を示しています。
Client Server
v v
| |
|\_____________ |
| RELEASE \|
| |
| Cancels lease
| |
| _____________/|
|/ ACK |
| |
v v
Figure 5: Timeline diagram of messages exchanged in Address Release example
図5：住所リリースの例で交換されるメッセージのタイムライン図
This is a continuation of the previous example. At some later time, the client decides to allocate another multicast address. Since it has recently worked with a server, it decides to try sending a unicast REQUEST to that server. If this doesn't work, it can always try a multicast DISCOVER, as illustrated in example 2.
これは、前の例の続きです。しばらくして、クライアントが別のマルチキャストアドレスを割り当てることにしました。それが最近サーバーで働いているので、それは、そのサーバにユニキャスト要求を送信しようとすることを決定します。これが機能しない場合の例2に示すように、それは常に、マルチキャストDISCOVERを試すことができます。
The client unicasts a REQUEST packet to the server from which it wants to allocate the address. This packet includes the Lease Time, Lease Identifier, and Multicast Scope options.
クライアントは、それがアドレスを割り当てることを望んでいるからサーバへのリクエストパケットをユニキャストします。このパケットは、リース期間、リース識別子、およびマルチキャストスコープオプションが含まれています。
The server responds with an ACK packet containing the Lease Time, Lease Identifier, and Multicast Scope options from the REQUEST packet, as well as the Server Identifier option and a List of Address Ranges option listing the address allocated.
サーバーは、割り当てられたアドレスをリストするオプションを範囲REQUESTパケットからリース期間、リース識別子、およびマルチキャストスコープオプションと同様に、サーバ識別子オプションとアドレスの一覧を含むACKパケットで応答します。
The client now has a lease on the multicast address.
クライアントは、マルチキャストアドレスのリースを持っています。
If the client had not received an ACK from the server, it would have retransmitted its REQUEST packet for a while. If it still received no response, it would start over with a multicast DISCOVER message.
クライアントがサーバからのACKを受け取っていなかった場合、それはしばらくの間、その要求パケットを再送しているだろう。それはまだ応答を受信しない場合には、マルチキャストDISCOVERメッセージをやり直すでしょう。
The following figure illustrates this exchange.
次の図は、この交換を示しています。
Client Server
v v
| |
|\_____________ |
| REQUEST \|
| |
| Allocates address
| |
| _____________/|
|/ ACK |
| |
v v
Figure 6: Timeline diagram of messages exchanged in Unicast Address Allocation example
図6：メッセージのタイムライン図は、ユニキャストアドレスの割り当て例で交換しました
APPENDIX B: Recommended Constant Values
付録B：推奨定数値
Table 6 lists recommended values for constants defined in this specification.
表6は、この仕様で定義されている定数の値を推奨します。
Constant Name Recommended Value
------------- -----------------
[CLOCK-SKEW-ALLOWANCE] 30 minutes
[DISCOVER-DELAY] current retransmit delay
[EXTRA-ALLOCATION-TIME] 1 hour
[NO-RESPONSE-DELAY] 60 seconds
[OFFER-HOLD] at least 60 seconds
[RESPONSE-CACHE-INTERVAL] at least 60 seconds (5 minutes maximum)
[XID-REUSE-INTERVAL] 10 minutes (required)
Table 6: Recommended Constant Values
表6：推奨定数値
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。