[要約] RFC 2730は、MADCAP（Multicast Address Dynamic Client Allocation Protocol）に関する規格です。MADCAPは、マルチキャストアドレスの動的なクライアント割り当てを目的としています。
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)
マルチキャストアドレスダイナミッククライアント割り当てプロトコル（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.
Copyright（c）The Internet Society（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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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].
[11]で定義され、[12]で変更されたマルチキャストIPマルチキャスト。
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.
たとえば、組織には複数のサイトがある場合があります。各サイトには独自のサイトローカルスコープゾーンがあり、それぞれがサイトローカルスコープのインスタンスになります。ただし、特定のホストの特定のインターフェイスは、特定のスコープの最大でのみである場合にしかありません。サイトローカルスコープゾーン内のホストからサイトローカルスコープのアドレスに送信されたメッセージは、ホストを含むサイトローカルスコープゾーンに限定されます。
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文字文字列。1つのゾーンには、それぞれ異なる言語のゾーン名がいくつかあります。たとえば、スイスのIBMの場所内で使用するゾーンには、「IBM Suisse」、「IBM Switzerland」、「IBM Schweiz」、および「Ibm Svizzera」という名前の名前が「言語タグ」、「en」、「de」、そして「それ」。
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またはホップカウント、およびこのスコープゾーンの1つ以上のゾーン名が含まれています。
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はDHCPとは完全に分離されており、2つと多くの有意差の間に依存関係はありません。
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クライアントがサービスをリクエストしたい場合、1つ以上の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.
再送信はクライアントによって処理されます。クライアントがメッセージを送信し、応答を受信しない場合、指数バックオフを使用して数回リクエストを再送信する場合があります。再送信リクエストを受信したときに同じクライアント要求を2回実行しないように、サーバーは短期間キャッシュ応答をキャッシュし、再送信リクエストを受信したときにキャッシュされた応答を再送信します。
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 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.
MSGTypeフィールドは、MADCAPメッセージの「タイプ」を定義する単一のオクテットです。現在定義されているメッセージタイプを表2に示します。それらは次のとおりです。発見、要求、更新、リリース、およびGetInfoメッセージは、クライアントによってのみ送信されます。オファー、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.
リクエスト、更新、およびリリースメッセージは、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メッセージをマルチキャストし、応答したいすべてのサーバーはUnicast 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.
発見メッセージは、おそらくリクエストを満たすことができるMadCapサーバーを発見するために使用されるメッセージです。メッセージは常にマルチキャストです。発見メッセージで提供されたパラメーターに対応する要求をおそらく満たすことができるサーバーは、必要なアドレスを一時的に予約し、クライアントにユニキャストオファーを送り返します。クライアントは、継続するためのサーバーを選択し、サーバーのサーバー識別子を含むマルチキャストリクエストを送信します。選択したサーバーは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.
MADCAP専用の予約ポート番号は、サーバー（IANAによって割り当てられたポート番号2535）で使用されます。任意のポート番号は、クライアントマシンで使用できます。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プロトコルバージョン番号（この仕様のゼロ）msgtype 1メッセージタイプ（発見、getInfoなど）addrfamily 2アドレスファミリ（IPv4、IPv6など）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フィールドは、IANAによって定義されたアドレスファミリ番号（[10]で定義されているものを含む）を使用して、この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-interval]（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]内の2つの異なるメッセージに使用される可能性は低いため、彼ら自身の間で通信しない複数のクライアントを超えて）。これにより、すべてのサーバー応答キャッシュ（次のいくつかの段落で説明されているように）からメッセージを削除し、ネットワークの遅延を採用するのに十分な時間を与えます。
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、およびリース識別子を持つメッセージを受信した場合、このメッセージを以前に受け取ったものの再送信として扱い、もしあれば応答を再送信する必要があります。[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分）までの値があり、サーバーのリソースの制約に応じて動的に調整される場合があります。ただし、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.
オプションフィールドには、最後のオプションが終了オプション（オプションコード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クライアントまたはサーバーには、セクション3にリストされているオプションが含まれている場合、表5の制限があります。また、将来定義される他の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.
メッセージ内のオプションの順序には重要なものがなく、任意の順序は同等の方法でサポートされなければなりません。ただし、最終オプションはメッセージごとに1回、オプションフィールドの最後のオプションとして発生する必要があります。
New MADCAP option codes may only be defined by IETF Consensus, as described in section 5.
新しいMADCAPオプションコードは、セクション5で説明されているように、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.
ただし、状況によっては、このドキュメントは、クライアントまたはサーバーが認識されている場合でも、特定のメッセージタイプを持つメッセージを無視することを必要とするか、示唆していることに注意してください。たとえば、発見メッセージを送信しないクライアントは、提供メッセージを無視する必要があります。また、セキュアサーバーは発見メッセージを無視する必要があり、すべてのサーバーは満たすことができない発見メッセージを無視する必要があります。
New MADCAP message types may only be defined by IETF Consensus, as described in section 5.
新しいMADCAPメッセージタイプは、セクション5で説明されているように、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クライアントは、発見メッセージを使用する必要はありません。他の方法を使用して、マルチキャスト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サーバーマルチキャストアドレスにマルチキャスト発見メッセージを送信することから始めます。クライアントに応答したいサーバーは、クライアントにユニキャストオファーメッセージを送信することで応答します。サーバーが、クライアントが要求したよりも短いリース時間以降の開始時間でのみリクエストを処理できる場合、提供できるリース時間または開始時間でオファーメッセージを送信する必要があります。ただし、クライアントが指定した最小リース時間や、クライアントが指定した最大開始時間よりも開始時間よりも短いリース時間を提供してはなりません。
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.
クライアントが発見メッセージを送信し、それに応じてオファーメッセージを受信しない場合、セクション2.3で説明されているように、クライアントは発見メッセージを再送信する必要があります。
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.
クライアントが発見メッセージを送信し、応答して1つ以上のオファーメッセージを受信した場合、使用するサーバーを選択し（もしあれば）、最初のオファーを受信した後に[Discover-Delay]内のサーバーを識別するマルチキャストリクエストメッセージを送信する必要がありますメッセージ。リクエストメッセージの詳細については、セクション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).
使用するサーバーを選択する際にクライアントが使用するメカニズムは、実装依存です。クライアントは、最初の許容可能な応答を選択するか、ある程度の期間（[Discover-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で指定されている現在の再送信タイマーです。あまりにも長い待機（[オファーホールド]に近づく）により、サーバーが予約したアドレスをドロップする可能性があります。
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 MUST always be included.
MADCAPクライアントが発見メッセージを送信すると、リース時間、最小リース時間、開始時間、最大開始時間、リクエストされたアドレスの数、およびアドレス範囲のリストが含まれ、受信したいアドレスを説明します。ただし、これらのオプションを含める必要はありません。これらのオプションのいずれかが含まれていない場合、サーバーは適切なデフォルトを提供します（リース時間に最大限、最小リース時間は最小限なし、開始時間はできるだけ早く、最大開始時間は最大ではありません。リクエストされた、およびアドレスの範囲のリストで利用可能なアドレス）。マルチキャストスコープオプションは、サーバーがどのスコープを使用するかを把握できるように、発見メッセージに含める必要があります。開始時間または最大開始時間オプションが含まれている場合は、現在の時間オプションを含める必要があります。リース識別子オプションを常に含める必要があります。
The OFFER message is a unicast message sent by a MADCAP server in response to a DISCOVER message that it can probably satisfy.
オファーメッセージは、おそらく満たすことができる発見メッセージに応じて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サーバーは、発見メッセージに応じてオファーメッセージを送信する必要はありません。たとえば、クライアントの要求を満たすことができない場合や、特定の種類の発見メッセージにのみ応答するように構成されているか、発見メッセージをまったく返信しないように構成されている可能性があります。
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サーバーがオファーメッセージを送信することを決定した場合、リース時間とマルチキャストスコープオプションを含めて、提供するアドレスを説明する必要があります。ただし、アドレス範囲のリストオプションを含める必要はありません。アドレス範囲の割り当てられたオプションのリストが含まれていない場合、サーバーがクライアントが要求したアドレスの数を喜んで提供すると想定されています。開始時間オプションが含まれていない場合、サーバーはクライアントが要求する開始時間を喜んで提供することを想定されます（もしあれば）。開始時間オプションが含まれている場合は、現在の時刻オプションを含める必要があります。
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.
サーバーがクライアントが要求したよりも短いリース時間以降の開始時間でリクエストを処理できる場合、提供できるリース時間または開始時間を使用してオファーメッセージを送信する必要があります。ただし、クライアントが指定した最小リース時間や、クライアントが指定した最大開始時間よりも開始時間よりも短いリース時間を提供してはなりません。
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.
サーバーがオファーメッセージを送信する場合、トランザクションを完了するのに十分なアドレスを保持しようとする必要があります。これらのアドレスを保持している発見メッセージとそれ自体と一致しないサーバー識別子オプションと同じリース識別子オプションを使用してマルチキャストリクエストメッセージを受信した場合、アドレスの保持を停止するはずです。また、トランザクションが完了していない場合、適切な遅延[申し出]の後、サーバーはアドレスの保持を停止する必要があります。この遅延の値は実装固有ですが、少なくとも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フィールドと一致する必要があります。クライアントリクエストに含まれる値と一致する値は、リース識別子オプションを含める必要があります。サーバー識別子オプションを含める必要があり、値はサーバーの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.
リクエストメッセージは、1つ以上のマルチキャストアドレスを割り当てたいMADCAPクライアントによって使用されます。既存のリースの更新には使用されません。更新メッセージはそのために使用されます。
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.
リクエストメッセージが発見メッセージによって開始されたトランザクションが完了している場合、すべてのMADCAPサーバーが選択されたサーバーを知っているように、次の手順に従う必要があります。クライアントは、発見メッセージが送信されたのと同じMADCAPサーバーマルチキャストアドレスへの要求メッセージをマルチキャストする必要があります。発見メッセージで使用されている同じリース識別子は、リクエストメッセージで使用する必要があります。また、選択したサーバーのサーバー識別子を使用して、サーバー識別子オプションを含める必要があります。
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.
リクエストメッセージが発見メッセージによって開始されたトランザクションが完了していない場合、リクエストメッセージは、クライアントが使用したい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クライアントがリクエストメッセージを送信すると、リース時間、最小リース時間、開始時間、リクエストされたアドレスの数、およびアドレス範囲のリストのリストが含まれ、受信したいアドレスを説明します。ただし、これらのオプションを含める必要はありません。これらのオプションのいずれかが含まれていない場合、サーバーは適切なデフォルトを提供します（リース時間に最大限、最小リース時間は最小限なし、開始時間はできるだけ早く、最大開始時間は最大ではありません。リクエストされた、およびアドレスの範囲のリストで利用可能なアドレス）。マルチキャストスコープオプションは、サーバーがどのスコープを使用するかを把握できるように、リクエストメッセージに含める必要があります。開始時間または最大開始時間オプションが含まれている場合は、現在の時間オプションを含める必要があります。
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で説明されているように、クライアントは要求メッセージを再送信する必要があります。
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.
サーバーがNAKで応答するか、合理的な（実装依存）遅延[no-response-delay]内で応答しない場合、クライアントは別のxidで発見メッセージを送信するか、リクエストメッセージを送信して別のサーバーを見つけようとする場合があります。別のサーバーへの別の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メッセージは、MADCAPサーバーによって使用され、GetInfo、要求、またはリリースメッセージに肯定的に応答します。サーバーは、応答しているメッセージを受け取ったクライアントに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メッセージがリクエストメッセージに応答している場合、リース時間、マルチキャストスコープ、およびアドレス範囲範囲のリストを含める必要があります。開始時間オプションが含まれる場合があります。開始時間オプションが含まれている場合、現在の時間オプションも含める必要があります。開始時間オプションが含まれていない場合、リースはすぐに開始すると想定されます。
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メッセージが更新メッセージに応答している場合、リース時間、マルチキャストスコープ、およびアドレス範囲範囲のリストを含める必要があります。開始時間オプションが含まれる場合があります。開始時間オプションが含まれている場合、現在の時間オプションも含める必要があります。開始時間オプションが含まれていない場合、リースはすぐに開始すると想定されます。
If the ACK message is responding to a RELEASE message, it MUST only include Server Identifier and Lease Identifier options.
ACKメッセージがリリースメッセージに応答している場合、サーバー識別子とリース識別子オプションのみを含める必要があります。
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フィールドと一致する必要があります。クライアントリクエストに含まれる値と一致する値は、リース識別子オプションを含める必要があります。サーバー識別子オプションを含める必要があり、値はサーバーの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フィールドと一致する必要があります。クライアントリクエストに含まれる値と一致する値は、リース識別子オプションを含める必要があります。サーバー識別子オプションを含める必要があり、値はサーバーのIPアドレスです。エラーオプションは、何がうまくいかなかったかを示すエラーコードに含める必要があります。パケットを再送信してはなりません。
The RENEW message is used by a MADCAP client that wants to renew a multicast address lease, changing the lease time or start time.
更新メッセージは、マルチキャストアドレスリースを更新し、リース時間または開始時間を変更したい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サーバーへの更新メッセージをユニキャストします。サーバーがリクエストを正常に処理できる場合、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.
更新されるリースは、更新メッセージで提供されているものと一致するリース識別子オプションで割り当てられたものです。
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クライアントが更新メッセージを送信すると、リース時間、最小リース時間、開始時間、および最大開始時間オプションが含まれ、受信したい新しいリースを説明します。ただし、これらのオプションを含める必要はありません。これらのオプションのいずれかが含まれていない場合、サーバーは適切なデフォルトを提供します（リース時間に最大限、最小リース時間は最小限、開始時間はできるだけ早く、最大の開始時間に最大限なしで提供されます）。開始時間または最大開始時間オプションが含まれている場合は、現在の時間オプションを含める必要があります。
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.
クライアントが更新メッセージを送信し、それに応じてACKまたはNAKメッセージを受信しない場合、セクション2.3で説明されているように、クライアントは更新メッセージを再送信する必要があります。
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.
サーバーがNAKで応答するか、合理的な（実装依存）遅延[no-response-delay]内で応答しない場合、サーバーモビリティ機能が使用されていれば、クライアントは別のサーバーに別のxidで更新メッセージを送信する場合があります。元のリクエストメッセージと、この機能が別のサーバーに送信された後続の更新メッセージに必要であることが必要です。サーバーモビリティ機能の詳細については、セクション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.
このリリースメッセージは、リースが期限切れになる前に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サーバーにリリースメッセージをユニカストします。選択したサーバーがリクエストを正常に処理できる場合、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.
リリースされるリースは、リリースメッセージに記載されているものと一致するリース識別子オプションで割り当てられたものです。アドレスの一部のみを単一のリースでリリースすることはできません。
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.
クライアントがリリースメッセージを送信し、それに応じてACKまたはNAKメッセージを受信しない場合、セクション2.3で説明されているように、クライアントはリリースメッセージを再送信する必要があります。
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を含むリリースメッセージを送信する場合があります。元のリクエストメッセージと、この機能が別のサーバーに送信された後続のリリースメッセージに必要であることが必要です。サーバーモビリティ機能の詳細については、セクション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秒、最大3回の再送信でこの遅延を2倍にすることです。時間に（秒単位で）最初の伝送が送信され、応答が受信されなかった場合、その後の送信はt 4、t 12、およびt 28になります。T60が応答を受け取っていない場合、クライアントは再送信を停止します。別のアクションコースを取得します（エラーのログや別のアドレスへのメッセージの送信など。
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.
新しいMADCAPリース識別子タイプは、セクション5で説明されているように、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フィールドとともに）、リース識別子を使用して、更新またはリリースリクエストが参照するリースを決定します。MADCAPサーバーは、初期リクエストメッセージで使用されているリース識別子を使用して、更新またはリリースメッセージに含まれるリース識別子と一致する必要があります。リース識別子が一致しない場合、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）。この後、2オクテットのIANA定義のアドレスファミリ番号（[10]で定義されているものを含む）、指定されたアドレスファミリからのアドレス、およびクライアント固有の識別子（シーケンス番号または現在の時刻など）があります。
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を選択して、XID、MSGTYPE、およびリース識別子の同じ組み合わせが[XID-Reuse-Interval]内の2つの異なるメッセージに使用される可能性が低い（複数の複数の異なるメッセージに使用される可能性が低い場合があります。彼ら自身の間でコミュニケーションをとらないクライアント）。クライアントまたはサーバーから送信された各メッセージに、リース識別子オプション、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で説明されているように、サーバーがコンテキストに対して無効であるためにメッセージを処理できない場合、サーバーは無効な要求エラーを生成および処理する必要があります。トランザクションは、マルチキャストアドレス（発見、提供、リクエスト、ACK、およびNAKメッセージで構成される）を割り当てる試み、リースを更新する試み（更新、ACK、およびNAKメッセージで構成される）、リリースの試みです。以前に割り当てられたマルチキャストアドレス（リリース、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を使用している場合は、最大TTLが16のIPv4ローカルスコープ（239.255.0.0/16）を使用する必要があります。IPv6を使用している場合は、最大ホップカウントを16で使用する必要があります。スコープリスト、Scopeリストを提供できる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クライアントが発見または要求のメッセージを使用してアドレスを要求する場合、アドレスを割り当てるべき管理範囲を指定する必要があります。このスコープは、マルチキャストスコープオプションで示されています。同様に、サーバーには、すべての提供メッセージとリクエストメッセージに応じて送信されたすべての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サーバーは、TTLSを含む255未満のスコープを含むスコープリストを返すことができます。MADCAPクライアントは、これらのスコープからアドレスを割り当てることができますが、そのようなアドレスに送信されたパケットのTTLフィールドを値に設定してはなりません。スコープリストに示されている最大TTLよりも大きい。このような環境では、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は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サーバーマルチキャストアドレスは、構成によって確立される場合があります。クライアントにそのような構成がない場合、特に構成されていない限り、最大TTLのIPv4ローカルスコープ（またはIPv6のSCOP 3）に関連付けられたMADCAPサーバーマルチキャストアドレス（IPv6のSCOP 3）を使用する必要があります。
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サーバーは、それらが存在しないスコープのサービスを提供できます。ただし、これは危険で複雑なテクニックであり、現時点では推奨されていません。したがって、MADCAPクライアントは、特に設定されていない限り、IPv4ローカルスコープ（またはIPv6を使用している場合はSCOP 3）に対応する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サーバーが存在しないスコープのサービスを提供する準備ができていない場合、スコープがリクエストを受信したMADCAPサーバーマルチキャストアドレスの範囲に一致しないか囲まれていないメッセージを無視して要求する必要があります。また、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メッセージに含める必要があります。発見、提供、要求、更新、または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時に1時間のクライアントが1時間から1時間のリースをリクエストするクライアントを1時間で要求していると仮定します。MADCAPに相対時間を使用している場合、クロックが正しく設定されているサーバーは、午後2時から3時のUTCのマルチキャストアドレスを予約し、リクエストを許可します。クライアントがリースを使用している唯一の人である場合、すべては問題ありません。クライアントは1時間でリースの使用を開始し、1時間続きます。これは、サーバーが予約されていた時間と一致します（ただし、クライアントは午後3時から午後4時のUTCだと思うでしょう）。
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は、電子メール、Web、またはその他のストアアンドフォワードメカニズムで送信される場合があるため、絶対時間を使用します。そのため、クライアントは午後3時から午後4時までのセッションを宣伝します。クロックが正しく設定されているクライアントは、このインターバル中にアドレスを使用します。サーバーは午後2時から午後3時までのアドレスのみを予約しているため、アドレスを複数のセッションに同時に使用する可能性があります。
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サーバーは、クライアントに指定されたリースの両側で、マルチキャストアドレスが余分な期間[追加配分時間]に割り当てられるようにすることにより、クライアントと少量のクロックスキューを期待し、許容する必要があります。ただし、大量のクロックスキューには特別な取り扱いが必要です。[追加配分時間]の値は、局所的な状況が異なる場合があるため、構成可能なパラメーターでなければなりません。推奨されるデフォルトは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 RECOMMENDED default is 30 minutes.
ただし、大量のクロックスキューは、セッションが宣伝されると後で問題を引き起こします。MADCAPサーバーが[Clock-Skew-Allowance]よりも大きいClock Skewを検出する場合、セクション2.6で説明されているように、過度のクロックスキューエラーを生成および処理する必要があります。サーバーはメッセージをログに記録することもできます。局所的な状況は異なる場合があるため、[クロックスケウアラウォワンス]の値は構成可能なパラメーターでなければなりません。推奨されるデフォルトは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つのOctet機能コードで識別されます。
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.
新しいMADCAP機能コードは、セクション5で説明されているように、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クライアントは、元の割り当てに使用されるサーバーと更新またはリリースに使用されるサーバーの両方によって機能が実装されるようにする必要があります。これを確実にするための最良の方法は、アドレスを割り当てるために使用されるリクエストメッセージの機能リストオプションの必要なリストにサーバーモビリティ機能を含めることです（および使用する場合は発見メッセージ）。アドレスを更新またはリリースする時が来たら、クライアントはユニキャストの更新メッセージを送信したり、アドレスを割り当てたサーバーにメッセージをリリースする必要があります。ただし、このサーバーが利用できない場合、クライアントは、サポートされている機能のリストにサーバーモビリティ機能を含む他のサーバーに更新またはリリースメッセージを送信できます。クライアントは、（たとえば）機能リストオプションコードを含むオプションリクエストリストオプションを使用して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.
クライアントは、リクエストされた機能リストオプションのリクエストまたは必須リストに再試行後の機能を含めてはなりません。
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値でリクエストメッセージを送信する必要があります。サーバーは、この時点で通常のACKまたはNAKメッセージを返す場合があります。または、ACKメッセージにアドレス範囲の空のリストオプションを含めることにより、後でトランザクションを継続する場合があります。リスト、および後でリクエストを再試行する必要がある後で、再試行時間オプションを使用します。
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.
retry Timeオプションを使用して最初の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.
リースを更新するときは、再試行後の機能も使用できます。この場合、上記の説明は、クライアントがリクエストメッセージの代わりに更新メッセージを送信することを除いて適用されます。
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つの更新メッセージで提供されるオプションは一致しません。セクション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.
このオプションは、クライアントのリクエスト（発見、要求、または更新）で使用され、クライアントがマルチキャストアドレスのリース時間を要求できるようにします。サーバーの返信（オファーまたは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 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3.3. Server Identifier
3.3. サーバー識別子
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アドレスが含まれています。[10]で定義されたものを含むIANAによって定義されている2つのオクテットアドレスファミリ番号が最初に保存され、その後アドレスが続きます。このアドレスの住所ファミリは、固定ヘッダーの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クライアントは、マルチキャストリクエストメッセージにサーバー識別子オプションを含める必要があります。
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.
マルチキャストスコープオプションは、クライアントが使用して、要求されたマルチキャストスコープを発見またはリクエストメッセージに示すようにします。また、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.
このオプションは、MADCAPクライアントがGetInfoメッセージで使用して、特定のオプションをサーバーのACK応答に含めることを要求します。サーバーは、指定されたオプションを応答に含めるようにしようとする必要がありますが、そうする必要はありません。
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.
クライアントは、このオプションを発見、更新、またはリクエストメッセージに含めて、将来の使用のためにマルチキャストアドレスを要求することができます。サーバーは、このオプションをオファーメッセージまたは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.
タイム値は、1970年1月1日以降、00:00 UTC以降の秒数を与えるネットワークバイトの順序で署名されていない32ビット整数です。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.
このオプションは、クライアントが要求する最小および望ましいアドレスの数を指定します。発見と要求メッセージでのみ使用され、クライアントによってのみ送信されます。
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つのアドレスのみを要求している場合、このオプションを含めるべきではありません。このオプションを含む発見またはリクエストパケットを受信するMADCAPサーバーには、オファーまたは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比較を使用）。いずれかの名前が一致する場合、そのうちの1つを返す必要があります。それ以外の場合、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値であり、名前数はこのゾーンのエンコード名の数です（これはゼロかもしれません）。スコープ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:
マルチキャストアドレスアロケーションサーバーでサポートされている2つのスコープがあります。アドレス239.192.0.0-239.195.255.255を備えたABCD.comの内部と、アドレス224.0.1.0-238.255.255.255のワールド。次に、このオプションは次のように与えられます：
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.
タイム値は、1970年1月1日以降、00:00 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つのOctet機能コードで識別されます。新しいMADCAP機能コードは、セクション5で説明されているように、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.
再試行時間オプションは、機能後に再試行を使用するときにクライアントがリクエストまたは更新メッセージを再試行する時間を指定します。
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サーバーによってのみ送信される必要があります。再試行の詳細については、セクション2.13.2を参照してください。
If the Retry Time option is present, the Current Time option MUST also be present.
再試行時間オプションが存在する場合、現在の時間オプションも存在する必要があります。
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.
タイム値は、1970年1月1日以降、00:00 UTC以降の秒数を与えるネットワークバイトの順序で署名されていない32ビット整数です。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.
このオプションは、クライアントのリクエスト（発見、要求、または更新）で使用され、クライアントがマルチキャストアドレスの最小リース時間を指定できるようにします。サーバーがこの最小リース時間を満たすことができない場合、セクション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.
クライアントは、このオプションを発見、更新、またはリクエストメッセージに含めて、指定された値よりも開始時間でリースを受信したくないことを指定できます。サーバーがこの最大開始時間を満たすことができない場合、セクション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.
タイム値は、1970年1月1日以降、00:00 UTC以降の秒数を与えるネットワークバイトの順序で署名されていない32ビット整数です。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.
エラーオプションの最初の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.
エラーオプションの残りのオクテットには、エラーに関する追加のデータが含まれています。このデータの形式は、エラーコードによって異なります。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を参照）。追加のデータは、現在の時刻のサーバーのアイデアを表す4オクテットの時間値、1970年1月1日00:00 UTC以降の秒数を与えるネットワークバイト順に署名されていない32ビット整数で構成されています。これはNTPに変換できます。10進数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は、リース識別子が認識されていないことを示します（通常、更新またはリリースメッセージに応じて）。追加のデータはありません。
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.
Rogue 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、Steve Deering、Peter Ford、Mark Handley、Van Jacobson、David Oran、Thomas Pfenning、Dave Thaler、Ramesh 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] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張機能」、RFC 2132、1997年3月。
[3] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[3] Meyer、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] Mills、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] Atkinson、R。およびS. Kent、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[10] Reynolds、J。およびJ. Postel、「割り当てられた番号」、STD 2、RFC 1700、1994年10月。
[11] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[11] Deering、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] Deering、S。and 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。and S. Deering、「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.、Frederick、R。and V. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、RFC 1889、1996年1月。
Stephen R. Hanna Sun Microsystems, Inc. One Network Drive Burlington, MA 01803
Stephen R. Hanna Sun Microsystems、Inc。One Network Drive Burlington、MA 01803
Phone: +1.781.442.0166
EMail: steve.hanna@sun.com
Baiju V. Patel Intel Corp. Mail Stop: AG2-201 5200 NE Elam Young Parkway Hillsboro, OR 97124
Baiju V. Patel Intel Corp. Mail Stop：AG2-201 5200 NE ELAM YOUNG PARKWAY HILLSBORO、または97124
Phone: 503 696 8192 EMail: baiju.v.patel@intel.com
電話：503 696 8192メール：baiju.v.patel@intel.com
Munil Shah Microsoft Corporation One Microsoft Way Redmond, WA 98052
Munil Shah Microsoft Corporation One Microsoft Way Redmond、WA 98052
Phone: 425 703 3924 EMail: munils@microsoft.com
電話：425 703 3924メール：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").
ACKメッセージを送信することにより、2つのMADCAPサーバーが応答します。これらのACKメッセージには、クライアント、サーバーのサーバー識別子、およびスコープごとに1つの名前を持つマルチキャストスコープリスト（言語タグ「EN」と最も密接に一致するマルチキャストスコープリストが含まれるリース識別子オプションとXIDが含まれます。
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サーバーマルチキャストアドレスへの発見パケットをマルチリキャストすることから始めます。このパケットには、リース時間、リース識別子、マルチキャストスコープオプションが含まれます。
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 Packetを受信し、このリクエストを満たすことができるサーバーは、クライアントのアドレスを一時的に予約し、クライアントへのオファーパケットをユニキャストします。これらのパケットには、リース時間、サーバー識別子、リース識別子、およびマルチキャストスコープオプションが含まれています。
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サーバーマルチキャストアドレスにリクエストパケットをマルチキャストします。このパケットには、発見パケットに含まれるすべてのオプションが含まれていますが、リクエスト用に選択したサーバーを示すサーバー識別子オプションも含まれています。
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.
サーバー識別子がクライアントによって指定されたサーバーと一致するサーバーは、オファーパケットに含まれるオプションを含むACKパケットと、割り当てられたアドレスをリストするアドレス範囲のリストのリストで応答します。提供されたパケットを送信した他のすべてのサーバーは、クライアントの住所の予約を停止し、交換全体を忘れてしまいます。
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を受信していなかった場合、しばらくリクエストパケットを再送信していました。それでも応答がなかった場合、新しい発見メッセージからやり直します。
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時間の期間を途中で、リースをさらに1時間延長したいと判断しました。
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.
クライアントは、アドレスを割り当てたサーバーに更新パケットをユニキャストします。このパケットには、リース時間とリース識別子オプションが含まれます。リース識別子は、元の割り当てに使用されるものと一致します。リース時間に含まれる時間は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時間延長しています。30分後、クライアントはマルチキャストアドレスの使用を終了し、再利用できるようにリリースしたいと考えています。
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.
クライアントは、アドレスを割り当てたサーバーにリリースパケットをユニキャストします。このパケットには、リース識別子オプションが含まれています。リース識別子は、元の割り当てに使用されるものと一致します。サーバーがこのパケットを受信すると、アドレス上のクライアントのリースがキャンセルされ、クライアントに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に示すように、常にマルチキャスト発見を試すことができます。
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.
サーバーは、リース時間、リース識別子、およびリクエストパケットからのマルチキャストスコープオプションを含む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を受信していなかった場合、しばらくリクエストパケットを再送信していました。それでも応答がなかった場合、マルチキャストの発見メッセージからやり直します。
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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。