RFC2730 日本語訳
2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP). S.Hanna, B. Patel, M. Shah. December 1999. (Format: TXT=120341 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループS.ハンナ要求をネットワークでつないでください: 2730年のサン・マイクロシステムズ・インクカテゴリ: 標準化過程B.パテルインテル社M.シャーMicrosoft Corp.1999年12月
Multicast Address Dynamic Client Allocation Protocol (MADCAP)
マルチキャストのアドレスのダイナミックなクライアント配分プロトコル(向こう見ず)です。
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This document defines a protocol, Multicast Address Dynamic Client Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers.
このドキュメントはプロトコル、ホストがマルチキャストアドレス配分サーバからマルチキャストアドレスを要求できるMulticast Address Dynamic Client Allocationプロトコル(MADCAP)を定義します。
1. Introduction
1. 序論
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.
マルチキャストAddress Dynamic Client Allocationプロトコル(MADCAP)はホストがマルチキャストアドレス配分サーバからマルチキャストアドレス配分サービスを要求できるプロトコルです。 このプロトコルはIETF Multicast Address Allocation作業部会によって定義されるMulticast Address Allocation Architectureの一部です。 しかしながら、それは別々にそのアーキテクチャの残りから適宜使用されるかもしれません。
1.1. Terminology
1.1. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [9].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[9]で説明されるように本書では解釈されることであるべきですか?
Constants used by this protocol are shown as [NAME-OF-CONSTANT], and summarized in Appendix B.
このプロトコルによって使用される定数は、[NAME-OF-CONSTANT]として示されて、Appendix Bにまとめられます。
Hanna, et al. Standards Track [Page 1] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[1ページ]。
1.2. Definitions
1.2. 定義
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クライアントかクライアントAホスト。
MADCAP server or server
A host providing multicast address allocation services via MADCAP.
MADCAPを通したMADCAPサーバかサーバAホスト提供マルチキャストアドレス配分サービス。
Multicast
IP Multicast, as defined in [11] and modified in [12].
[11]で定義されて、[12]で変更されるようなマルチキャストIP Multicast。
Multicast Address
An IP multicast address or group address, as defined in [11] and
[13]. An identifier for a group of nodes.
アドレスかグループが[11]と[13]で定義されるように扱うマルチキャストAddress An 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].
マルチキャストアドレスのマルチキャストScope A範囲は、したがって、これらのアドレスに送られたそのトラフィックがインターネットワークの何らかの部分集合に制限されるのを構成しました。 [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.
範囲のZone Oneマルチキャスト範囲には、いくつかのインスタンスか略してゾーンがあるかもしれません。(インスタンスはScope Zonesとして知られています)。
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.
例えば、組織には、複数のサイトがあるかもしれません。 各サイトにはそれ自身のサイト地方のScope Zoneがあるかもしれません。それはそれぞれサイト地方のScopeのインスタンスでしょう。 しかしながら、高々与えられた範囲の1つのインスタンスには与えられたホストの上の与えられたインタフェースがあるだけでしょう。 サイト地方のScopeのアドレスへのサイト地方のScope Zonesのホストによって送られたメッセージはホストを含むサイト地方のScope Zoneに制限されるでしょう。
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".
Scope ZoneのためのAゾーンのNameの人間の読み込み可能な名。 RFC1766[6]言語タグがあるISO10646文字列。 1つのゾーンには、それぞれ異なった言語のいくつかのゾーン名があるかもしれません。 例えば、スイスのIBMの位置の中の使用のためのゾーンには、言語タグ"fr"、「アン」、"de"、および「それ」の名前「IBMスイッシェ」、「IBMスイス」、「IBM Schweiz」、および「IBMスヴィツェラ」があるかもしれません。
Hanna, et al. Standards Track [Page 2] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[2ページ]。
Multicast Scope List
A list of multicast scope zones.
マルチキャスト範囲ゾーンのマルチキャストScope List Aリスト。
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クライアントはクライアントにとって、利用可能なゾーンのすべてを記載するMulticast Scope Listを供給するためにサーバをMADCAPに尋ねることができます。 それぞれの範囲ゾーンに、リストは、この範囲、最大のTTLまたはホップカウントがこの範囲、および1つ以上のゾーン名にこの範囲ゾーンに使用されるためにマルチキャストアドレスの範囲を含んでいます。
This definition applies only within this document.
この定義はこのドキュメントだけの中に適用されます。
1.3. Motivation and Protocol Requirements
1.3. 動機とプロトコル要件
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つの方法はクライアントを認証することです。 また、これは制定方針のための主要な前提条件です。
Hanna, et al. Standards Track [Page 3] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[3ページ]。
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.
会議サポート: 会議環境における使用のためのアドレスを割り当てるとき、会議のメンバーは会議に使用されるマルチキャストアドレスリースを変更できるべきです。
1.4. Relationship with DHCP
1.4. DHCPとの関係
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と多くの著しい違いの間の依存なしで完全に別々です。
1.5. Protocol Overview
1.5. プロトコル概要
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.
Retransmissionはクライアントによって扱われます。 クライアントがメッセージを送って、応答を受けないなら、それは、指数のbackoffを使用することで要求を数回再送するかもしれません。 同じクライアントを処刑するのを避けるには、二度再送された要求を受け取るとき再送された要求が受信されているとき、サーバが短期間の間、応答をキャッシュして、キャッシュされた応答を再送するよう要求してください。
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、およびLease Identifierオプションを含んでいます。 クライアントはこの三重が確実にたぶん[XID-REUSE-INTERVAL](10分)の期間、MADCAPサーバによって受け取られたすべてのMADCAPメッセージの向こう側にユニークになるようにしなければなりません。 これで、MADCAPサーバはキーとして応答キャッシュにこの三重を使用できます。
Messages sent by servers include the xid included in the original request so that clients can match up responses with requests.
サーバによって送られたメッセージは、クライアントが要求による応答を合わせることができるようにオリジナルの要求にxidを含んでいるのを含んでいます。
The msgtype field is a single octet that defines the "type" of a MADCAP message. Currently defined message types are listed in Table 2. They are: DISCOVER, OFFER, REQUEST, RENEW, ACK, NAK, RELEASE, and
msgtype分野はMADCAPメッセージの「タイプ」を定義するただ一つの八重奏です。 現在定義されたメッセージタイプはTable2に記載されています。 それらは以下の通りです。 NAK、ACK、申し出、要求が更新されると発見してください、リリース
Hanna, et al. Standards Track [Page 4] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[4ページ]。
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.
GETINFO。 DISCOVER、REQUEST、RENEW、RELEASE、およびGETINFOメッセージはクライアントによって送られるだけです。 サーバはOFFER、ACK、およびNAKメッセージを送るだけです。
The REQUEST, RENEW, and RELEASE messages are used to request, renew, or release a lease on one or more multicast addresses. A client unicasts one of these messages to a server and the server responds with an ACK or a NAK.
REQUEST、RENEW、およびRELEASEメッセージは、1つ以上のマルチキャストアドレスでリースを要求するか、更新するか、またはリリースするのに使用されます。 サーバとサーバへのこれらのメッセージの1つがACKかNAKと共に反応させるクライアントユニキャスト。
The GETINFO message is used to request information, such as the multicast scope list, or to find MADCAP servers. A client may unicast an GETINFO message to a MADCAP server. However, it may not know the IP address of any MADCAP server. In that case, it will multicast an GETINFO message to a MADCAP Server Multicast Address and all servers that wish to respond will send a unicast ACK or NAK back to the client.
GETINFOメッセージは、マルチキャスト範囲リストなどの情報を要求するか、またはMADCAPにサーバを見つけるのに使用されます。 しかしながら、それはどんなMADCAPサーバのIPアドレスも知らないかもしれません。クライアントがそうするかもしれない、GETINFOが通信させるユニキャスト、a MADCAPサーバその場合、それはMADCAP Server Multicast AddressへのGETINFOメッセージをマルチキャストに望んでいて、応じたがっているすべてのサーバがACKかNAKがクライアントに支持するユニキャストを送るでしょう。
Each multicast scope has an associated MADCAP Server Multicast Address. This address has been reserved by the IANA as the address with a relative offset of -1 from the last address of a multicast scope. MADCAP clients use this address to find MADCAP servers.
それぞれのマルチキャスト範囲には、関連MADCAP Server Multicast Addressがあります。 このアドレスはアドレスとして-1の相対的なオフセットでIANAによってマルチキャスト範囲の最後のアドレスから予約されました。 MADCAPクライアントは、MADCAPにサーバを見つけるのにこのアドレスを使用します。
The DISCOVER message is a message used to discover MADCAP servers that can probably satisfy a REQUEST. DISCOVER messages are always multicast. Servers that can probably satisfy a REQUEST corresponding to the parameters supplied in the DISCOVER message temporarily reserve the addresses needed and send a unicast OFFER back to the client. The client selects a server with which to continue and sends a multicast REQUEST including the server's Server Identifier to the same multicast address used for the DISCOVER. The chosen server responds with an ACK or NAK and the other servers stop reserving the addresses they were temporarily holding.
DISCOVERメッセージはたぶんREQUEST. DISCOVERメッセージを満たすことができるMADCAPサーバがいつもマルチキャストであると発見するのに使用されるメッセージです。 たぶんDISCOVERメッセージで提供されたパラメタに対応するREQUESTを満たすことができるサーバが、一時必要であるアドレスを予約して、クライアントへのユニキャストOFFER後部を送ります。 クライアントは、続くサーバを選択して、同じマルチキャストアドレスへのサーバのServer Identifierが. 選ばれたサーバがACKかNAKと共に反応させるDISCOVERに使用したマルチキャストREQUEST包含ともう片方のサーバ停止にそれらが一時保持していたアドレスを予約させます。
For detailed descriptions of typical protocol exchanges, consult Appendix A.
典型的なプロトコル交換の詳述には、Appendix 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サーバは、独身のクライアントに割り当てられたマルチキャストアドレスの数を制限するために構成されるかもしれません。 適切にそのような限界を実施するのはSecurity Consideration部で説明されるように暗号のセキュリティを必要とします。
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つの要求が特定のオプション機能(Retry Afterのような)をサポートするのでそのクライアントからの今後の要求がそのオプション機能をサポートすると仮定してはいけません。
Hanna, et al. Standards Track [Page 5] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[5ページ]。
2. Protocol Description
2. プロトコル記述
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プロトコルはクライアント/サーバプロトコルです。 一般に、クライアントのユニキャストかマルチキャストaが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によって割り当てられるようにNo.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に提供します。
2.1. Message Format
2.1. メッセージ・フォーマット
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メッセージの書式を与えます、そして、Table1は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バイト)を保持できないくらい不足しているどんなメッセージも無視しなければなりません。
Hanna, et al. Standards Track [Page 6] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[6ページ]。
+-+-+-+-+-+-+-+-+
| version (1) |
+---------------+
| msgtype (1) |
+---------------+
| addrfamily |
| (2) |
+---------------+
| |
| xid (4) |
| |
| |
+---------------+
| |
| options |
| (variable) |
| ... |
+---------------+
+-+-+-+-+-+-+-+-+ | バージョン(1)| +---------------+ | msgtype(1)| +---------------+ | addrfamily| | (2) | +---------------+ | | | xid(4)| | | | | +---------------+ | | | オプション| | (可変)です。 | | ... | +---------------+
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プロトコルバージョン番号(この仕様のためのゼロ)msgtype1Messageは4Transaction IDオプションvar Optionsがさばくaddrfamily2Addressファミリー(IPv4、IPv6など)xidをタイプします(DISCOVER、GETINFOなど)。
Table 1: Description of fields in a MADCAP message
テーブル1: MADCAPメッセージにおける、分野の記述
2.1.1. The version field
2.1.1. バージョン分野
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.
いつもバージョン分野はプロトコルのこのバージョンのためのゼロでなければなりません。 この分野に他の値を含んでいるどんなメッセージも無視しなければなりません。
2.1.2. The msgtype field
2.1.2. msgtype分野
The msgtype field defines the "type" of the MADCAP message.
msgtype分野はMADCAPメッセージの「タイプ」を定義します。
For more information about this field, see section 2.2.
この分野に関する詳しい情報に関しては、セクション2.2を見てください。
Hanna, et al. Standards Track [Page 7] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[7ページ]。
2.1.3. The addrfamily field
2.1.3. addrfamily分野
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分野はこのMADCAPメッセージのために、デフォルトアドレスファミリー(IPv4かIPv6などの)を定義します、中でIANAによって定義されたアドレスファミリーナンバを使用して。([10])で定義されたものを含んでいます。 別の方法で指定されないと、メッセージにすべてのアドレスを含んでいるのはこのファミリーから来ているでしょう。
2.1.4. The xid field
2.1.4. xid分野
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、およびLease Identifierの組み合わせは[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、およびLease Identifierの同じ組み合わせが2つの異なったメッセージに使用されるのが[XID-REUSE-INTERVAL]の中でありそうもなくならなければなりません(どれがそうしないかは自分たちの中で複数のクライアントの向こう側にさえ、交信します)。 これは、十分な時間、すべてのサーバ応答キャッシュ(次の数パラグラフで説明されるように)とどんなネットワーク遅延のためにも下げられるべきメッセージがaccomodatedされるのを許容します。
The RECOMMENDED technique for choosing an xid is to choose a random four octet number as the first xid in a session and increment this value each time a new xid is needed. The random number chosen need not be cryptographically random. The random number may be chosen via any suitable technique, such as the one described in section A.6 of RFC 1889 [14].
xidを選ぶためのRECOMMENDEDのテクニックは、セッションにおける最初のxidとして無作為の4八重奏番号を選んで、新しいxidが必要であるたびにこの値を増加することです。 選ばれた乱数は暗号でそうである必要はありません。無作為。 乱数はどんな適当なテクニックでも選ばれるかもしれません、RFC1889[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を使用する、そして、Lease Identifier。
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
1つが[RESPONSE-CACHE-INTERVAL]の中で受信されたのでサーバが同じxid、msgtype、およびLease Identifierと共にメッセージを受け取るなら、それは、以前に容認されたものの「再-トランスミッション」としてこのメッセージを扱って、もしあれば応答を再送しなければなりません。 [RESPONSE-CACHE-INTERVAL]の後に、サーバは、以前に受信されたメッセージを忘れて、扱われるかもしれません。
Hanna, et al. Standards Track [Page 8] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[8ページ]。
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.
まるでそれらが新しいかのようにこのメッセージのどんな「再-トランスミッション」も通信します。 もちろん、結局そのメッセージを無視するなら、サーバはメッセージをキャッシュする必要はありません。 しかしながら、性能向上は、そうすることによって、獲得されるかもしれません。
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秒未満の使用するのは、NOT RECOMMENDEDです。
2.1.5. The options field
2.1.5. オプション分野
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.
オプション・フィールドはEndオプション(オプションコード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クライアントやサーバもTable5とほかの場所にセクション3で制限を条件として本書では記載されたオプションのいずれも入れるかもしれません。 また、彼らは将来定義される他のMADCAPオプションを含むかもしれません。 MADCAPクライアントかサーバが同じオプションタイプが1つのMADCAPメッセージにある1つ以上のオプションを入れてはいけません。
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で説明された方法で、Invalid Request誤りを生成されて、処理しなければなりません。 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.
メッセージの中のオプションの注文を意味を全く持たないで、同等な方法でサポートしなければならなくて、いずれも、命令するEndオプションがそうしなければならない例外で1メッセージに一度起こってください、オプション・フィールドにおける最後のオプションとして。
Hanna, et al. Standards Track [Page 9] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[9ページ]。
New MADCAP option codes may only be defined by IETF Consensus, as described in section 5.
新しいMADCAPオプションコードはセクション5で説明されるようにIETF Consensusによって定義されるだけであるかもしれません。
2.2. Message Types
2.2. メッセージタイプ
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
値のメッセージタイプ----- ------------ 1 2申し出3要求4が5ACK6NAK7リリース8GETINFOを取り替えると発見してください。
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メッセージタイプの記述があります。 テーブル5(セクション3の始めに現れます)はオプションがそれぞれのメッセージタイプで許容されているものをまとめます。
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で説明された方法で、Invalid Request誤りを生成されて、処理しなければなりません。 MADCAPクライアントがそれがメッセージタイプを見分けないメッセージを受け取るなら、それはメッセージを無視しなければなりません。
Note, however, that under some circumstances this document requires or suggests that clients or servers ignore messages with certain message types even though they may be recognized. For instance, clients that do not send DISCOVER messages SHOULD ignore OFFER messages. Also, secure servers SHOULD ignore DISCOVER messages and all servers SHOULD ignore DISCOVER messages that they cannot satisfy.
しかしながら、このドキュメントが、彼らが認識されるかもしれませんが、クライアントかサーバが、あるメッセージタイプがあるメッセージを無視するのをいくつかの状況で、必要である、または示すことに注意してください。 例えば、DISCOVERメッセージSHOULDを送らないクライアントがOFFERメッセージを無視します。 また、安全なサーバーSHOULDはDISCOVERメッセージを無視します、そして、すべてのサーバSHOULDが彼らが満足させることができないというDISCOVERメッセージを無視します。
New MADCAP message types may only be defined by IETF Consensus, as described in section 5.
新しいMADCAPメッセージタイプはセクション5で説明されるようにIETF Consensusによって定義されるだけであるかもしれません。
Hanna, et al. Standards Track [Page 10] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[10ページ]。
2.2.1. GETINFO
2.2.1. GETINFO
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 Server Multicast Addressへの特定のMADCAPサーバかマルチキャストへのユニキャストであるかもしれません。 MADCAP Server Multicast Addressに関するその他の詳細に関しては、セクション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メッセージがOption Request Listオプションを含まなければなりません。 SHOULDがそうしようとするサーバは、応答における指定されたオプションを含んでいますが、そうするのに必要ではありません(特にそれらを認識しないなら)。
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.
クライアントは、aであるならGETINFOメッセージを送って、応答におけるどんなACKメッセージも受け取りません、それ。SHOULDは説明されるとしてセクション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メッセージを送るとき、それはRequested Languageオプションを含むかもしれません。(それは、クライアントがMulticast Scope Listのゾーン名のためにどの言語を好むかを指定します)。 Multicast Scope Listオプションの定義でゾーン名に関してこのタグを扱う適切な方法について議論します。
2.2.2. DISCOVER
2.2.2. 発見します。
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メッセージはたぶんREQUESTを満たすことができるMADCAPサーバを発見したがっているMADCAPクライアントによって送られたマルチキャストメッセージです。
MADCAP clients are not required to use the DISCOVER message. They MAY employ other methods to find MADCAP servers, such as sending a multicast GETINFO message, caching an IP address that worked in the past or being configured with an IP address. Using the DISCOVER message has the particular advantage that it allows clients to receive responses from all servers that can satisfy the request.
MADCAPクライアントはDISCOVERメッセージを使用する必要はありません。 彼らはMADCAPにサーバを見つける他のメソッドを使うかもしれません、マルチキャストGETINFOメッセージを送るのなどように、過去に働いていたIPアドレスをキャッシュするか、またはIPアドレスによって構成されて。 DISCOVERメッセージを使用するのにおいて、それでクライアントを応答を要望に応じることができるすべてのサーバから受ける特定の利点があります。
Hanna, et al. Standards Track [Page 11] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[11ページ]。
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クライアントは、マルチキャストDISCOVERメッセージをMADCAP Server Multicast Addressに送ることによって、始めます。 クライアントを補助したがっているどんなサーバも、ユニキャストOFFERメッセージをクライアントに送ることによって、反応します。 サーバがそうすることができるだけであるなら、より短いリース間かクライアントが要求したより遅い開始時刻で要求を処理してください、それ。SHOULDはそれが提供できるリース時間か開始時刻があるOFFERメッセージを送ります。 しかしながら、それは最大の開始時刻がクライアントで指定したより遅く、最小のリース時間がクライアントで指定したより短いリース間か開始時刻を提供してはいけません。
For more details about the MADCAP Server Multicast Address, see section 2.10.
MADCAP Server Multicast Addressに関するその他の詳細に関しては、セクション2.10を見てください。
If a client sends a DISCOVER message and does not receive any OFFER messages in response, the client SHOULD retransmit its DISCOVER message, as described in section 2.3.
クライアントがDISCOVERメッセージを送って、応答におけるどんなOFFERメッセージも受け取らないなら、クライアントSHOULDはDISCOVERメッセージを再送します、セクション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.
クライアントがDISCOVERメッセージを送って、受信するなら、1OFFERが応答で通信します、それ。SHOULDはそれが使用したがっている(もしあれば)サーバを選択して、最初のOFFERメッセージを受け取った後に[DISCOVER-DELAY]の中でそのサーバを特定して、マルチキャストREQUESTメッセージを送ります。 REQUESTメッセージに関する詳しい情報に関してセクション2.2.4を見てください。
The mechanism used by the client in selecting the server it wants to use is implementation dependent. The client MAY choose the first acceptable response or it MAY wait some period of time (no more than [DISCOVER-DELAY]) and choose the best response received in that period of time (if the first response has a smaller lease time than requested, for instance).
それが使用したがっているサーバを選択する際にクライアントによって使用されたメカニズムは実装に依存しています。 クライアントが最初の許容できる応答を選ぶかもしれないか、それは、いつかの期間([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]の値も実装に依存していますが、RECOMMENDED値は現在の再送信タイマです、セクション2.3で指定されるように。 あまりに長い間待つのは(アプローチ[OFFER-HOLD])サーバにそれらが予約したアドレスを下げさせるかもしれません。
When a MADCAP client sends a DISCOVER message, it MAY include the Lease Time, Minimum Lease Time, Start Time, Maximum Start Time, Number of Addresses Requested, and List of Address Ranges options, describing the addresses it wants to receive. However, it need not include any of these options. If one of these options is not included, the server will provide the appropriate default (maximum available for Lease Time, no minimum for Minimum Lease Time, as soon as possible for Start Time, no maximum for Maximum Start Time, one for Number of Addresses Requested, and any addresses available for List of Address Ranges). The Multicast Scope option MUST be included in the DISCOVER message so that the server knows what scope should be used. The Current Time option MUST be included if the Start Time or Maximum Start Time options are included. The Lease Identifier option
MADCAPクライアントがDISCOVERメッセージを送るとき、Lease Timeを含むかもしれません、Minimum Lease Time、Start Time、Maximum Start Time、Addresses Requested、およびAddress RangesオプションのListのNumberがそれが受け取りたがっているアドレスについて説明して。 しかしながら、それはこれらのオプションのいずれも含む必要はありません。 これらのオプションの1つが含まれていないと、サーバが適切なデフォルトを提供する、(Lease Timeに利用可能な最大、Minimum Lease Timeのための最小限がない、できるだけ早さ、Start Time、Maximum Start Timeのための最大がない、Addresses RequestedのNumberのためのもの、およびAddress RangesのListに利用可能などんなアドレスも) DISCOVERメッセージにMulticast Scopeオプションを含まなければならないので、サーバは、どんな範囲が使用されるべきであるかを知っています。 Start TimeかMaximum Start Timeオプションが含まれているなら、Current Timeオプションを含まなければなりません。 Lease Identifierオプション
Hanna, et al. Standards Track [Page 12] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[12ページ]。
MUST always be included.
いつも含まなければなりません。
2.2.3. OFFER
2.2.3. 申し出
The OFFER message is a unicast message sent by a MADCAP server in response to a DISCOVER message that it can probably satisfy.
OFFERメッセージはMADCAPサーバによってたぶん満足させることができるというDISCOVERメッセージに対応して送られたユニキャストメッセージです。
A MADCAP server is never required to send an OFFER message in response to a DISCOVER message. For instance, it may not be able to satisfy the client's request or it may have been configured to respond only to certain types of DISCOVER messages or not to respond to DISCOVER messages at all.
MADCAPサーバは、DISCOVERメッセージに対応してOFFERメッセージを送るのに決して必要ではありません。 例えば、クライアントの要望に応じることができないかもしれませんか、またはそれは、あるタイプに関するDISCOVERメッセージだけに応じるか、またはDISCOVERメッセージに応じないように全く構成されたかもしれません。
If a MADCAP server decides to send an OFFER message, it MUST include the Lease Time and Multicast Scope options, describing the addresses it is willing to provide. However, it need not include the List of Address Ranges option. If the List of Address Ranges Allocated option is not included, it is assumed that the server is willing to provide the number of addresses that the client requested. If the Start Time option is not included, it is assumed that the server is willing to provide the start time requested by the client (if any). The Current Time option MUST be included if the Start Time option is included.
MADCAPサーバが、OFFERメッセージを送ると決めるなら、Lease TimeとMulticast Scopeオプションを含まなければなりません、それが提供しても構わないと思っているアドレスについて説明して。 しかしながら、それはAddress RangesオプションのListを含む必要はありません。 Address Ranges AllocatedオプションのListが含まれていないなら、サーバが、クライアントが要求したアドレスの数を提供しても構わないと思っていると思われます。 Start Timeオプションが含まれていないなら、サーバが、クライアント(もしあれば)によって要求された開始時刻を提供しても構わないと思っていると思われます。 Start Timeオプションが含まれているなら、Current Timeオプションを含まなければなりません。
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.
サーバがそうすることができるなら、より短いリース間かクライアントが要求したより遅い開始時刻で要求を処理してください、それ。SHOULDはそれが提供できるリース時間か開始時刻があるOFFERメッセージを送ります。 しかしながら、それは最大の開始時刻がクライアントで指定したより遅く、最小のリース時間がクライアントで指定したより短いリース間か開始時刻を提供してはいけません。
If the server sends an OFFER message, it SHOULD attempt to hold enough addresses to complete the transaction. If it receives a multicast REQUEST message with the same Lease Identifier option as the DISCOVER message for which it is holding these addresses and a Server Identifier option that does not match its own, it SHOULD stop holding the addresses. The server SHOULD also stop holding the addresses after an appropriate delay [OFFER-HOLD] if the transaction is not completed. The value of this delay is implementation-specific, but a value of at least 60 seconds is RECOMMENDED.
サーバはOFFERメッセージを送って、それは取引を完了できるくらいのアドレスを保持するSHOULD試みです。 それがこれらのアドレスとServer Identifierオプションを保持しているDISCOVERメッセージと同じLease IdentifierオプションでマルチキャストREQUESTメッセージを受け取るなら、それはそれ自身のものに合わないで、それはアドレスを保持するSHOULD停止です。 また、サーバSHOULDは、取引が完了されないなら適切な遅れ[OFFER-HOLD]の後にアドレスを保持するのを止めます。 この遅れの値は実装特有ですが、少なくとも60秒の値はRECOMMENDEDです。
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分野は合わなければなりません。 クライアント要求にものを含んでいて、値が合っていて、Lease Identifierオプションを含まなければなりません。 サーバのIPアドレスである値でServer Identifierオプションを含まなければなりません。 そして、パケットを再送してはいけません。
Hanna, et al. Standards Track [Page 13] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[13ページ]。
2.2.4. REQUEST
2.2.4. 要求
The REQUEST message is used by a MADCAP client that wants to allocate one or more multicast addresses. It is not used for renewing an existing lease. The RENEW message is used for that.
REQUESTメッセージは1つ以上のマルチキャストアドレスを割り当てたがっているMADCAPクライアントによって使用されます。 それは、既存のリースを更新するのに使用されません。 RENEWメッセージはそれに使用されます。
If a REQUEST message is completing a transaction initiated by a DISCOVER message, the following procedure MUST be followed so that all MADCAP servers know which server was selected. The client MUST multicast a REQUEST message to the same MADCAP Server Multicast Address that the DISCOVER message was sent to. The same Lease Identifier used in the DISCOVER message MUST be used in the REQUEST message. Also, the Server Identifier option MUST be included, using the Server Identifier of the server selected.
REQUESTメッセージがDISCOVERメッセージによって開始された取引を完了しているなら、以下の手順に従わなければならないので、すべてのMADCAPサーバが、どのサーバが選択されたかを知っています。 クライアントはDISCOVERメッセージが送られた同じMADCAP Server Multicast Addressへのマルチキャストa REQUESTメッセージがそうしなければなりません。 REQUESTメッセージでDISCOVERメッセージで使用される同じLease Identifierを使用しなければなりません。 また、選択されたサーバのServer Identifierを使用して、Server Identifierオプションを含まなければなりません。
If a REQUEST message is not completing a transaction initiated by a DISCOVER message, the REQUEST message MUST be unicast to the MADCAP server that the client wants to use. In this case, the Server Identifier option MAY be included, but need not be.
REQUESTメッセージがDISCOVERメッセージによって開始された取引を完了していないなら、REQUESTメッセージはクライアントが使用したがっているMADCAPサーバへのユニキャストであるに違いありません。 この場合、Server Identifierオプションは、含まれるかもしれませんが、ある必要はありません。
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がクライアントへ通信させるSHOULDユニキャストです。 そうでなければ、それ、SHOULDはセクション2.6で説明された方法で、誤りを生成して、処理します。 サーバがそうすることができるなら、より短いリース間かクライアントが要求したより遅い開始時刻で要求を処理してください、それ。SHOULDはそれが提供できるリース時間か開始時刻がある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クライアントがREQUESTメッセージを送るとき、Lease Timeを含むかもしれません、Minimum Lease Time、Start Time、Maximum Start Time、Addresses Requested、およびAddress RangesオプションのListのNumberがそれが受け取りたがっているアドレスについて説明して。 しかしながら、それはこれらのオプションのいずれも含む必要はありません。 これらのオプションの1つが含まれていないと、サーバが適切なデフォルトを提供する、(Lease Timeに利用可能な最大、Minimum Lease Timeのための最小限がない、できるだけ早さ、Start Time、Maximum Start Timeのための最大がない、Addresses RequestedのNumberのためのもの、およびAddress RangesのListに利用可能などんなアドレスも) REQUESTメッセージにMulticast Scopeオプションを含まなければならないので、サーバは、どんな範囲が使用されるべきであるかを知っています。 Start TimeかMaximum Start Timeオプションが含まれているなら、Current Timeオプションを含まなければなりません。
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.
クライアントがREQUESTメッセージを送って、応答におけるどんなACKやNAKメッセージも受け取らないなら、クライアントSHOULDはREQUESTメッセージを再送します、セクション2.3で説明されるように。
Hanna, et al. Standards Track [Page 14] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[14ページ]。
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と共にこたえるか、または妥当な(実装依存する)遅れ[RESPONSE-DELAYがない]の中で応じないなら、クライアントは、別のxidで別のxidか発信があるDISCOVERメッセージを送るのによる別のサーバがREQUESTメッセージであることが別のサーバにわかろうとするかもしれません。[RESPONSE-DELAYがありません]のためのRECOMMENDED値は60秒です。
2.2.5. ACK
2.2.5. ACK
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、REQUEST、またはRELEASEメッセージに積極的に応じます。 サーバユニキャスト、それが応じているメッセージを受け取ったクライアントへの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メッセージに応じていて、それはどんなオプションもOption Request Listオプションを使用しているクライアントから要求したSHOULDインクルードです。
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メッセージがREQUESTメッセージに応じているなら、それはAddress RangesオプションのLease Time、Multicast Scope、およびListを含まなければなりません。 それはStart Timeオプションを含むかもしれません。 また、Start Timeオプションが含まれているなら、Current Timeオプションを含まなければなりません。 どんなStart Timeオプションも含まれていないなら、リースがすぐに始まると思われます。
If the ACK message is responding to a RENEW message, it MUST include Lease Time, Multicast Scope, and List of Address Ranges options. It MAY include a Start Time option. If a Start Time option is included, a Current Time option MUST also be included. If no Start Time option is included, the lease is assumed to start immediately.
ACKメッセージがRENEWメッセージに応じているなら、それはAddress RangesオプションのLease Time、Multicast Scope、およびListを含まなければなりません。 それはStart Timeオプションを含むかもしれません。 また、Start Timeオプションが含まれているなら、Current Timeオプションを含まなければなりません。 どんなStart Timeオプションも含まれていないなら、リースがすぐに始まると思われます。
If the ACK message is responding to a RELEASE message, it MUST only include Server Identifier and Lease Identifier options.
ACKメッセージがRELEASEメッセージに応じているなら、それはServer IdentifierとLease Identifierオプションを含むだけでよいです。
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分野は合わなければなりません。 クライアント要求にものを含んでいて、値が合っていて、Lease Identifierオプションを含まなければなりません。 サーバのIPアドレスである値でServer Identifierオプションを含まなければなりません。 そして、パケットを再送してはいけません。
2.2.6. NAK
2.2.6. NAK
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メッセージ。
Hanna, et al. Standards Track [Page 15] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[15ページ]。
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分野は合わなければなりません。 クライアント要求にものを含んでいて、値が合っていて、Lease Identifierオプションを含まなければなりません。 サーバのIPアドレスである値でServer Identifierオプションを含まなければなりません。 エラーコードが、何が支障をきたしたかを示していて、Errorオプションを含まなければなりません。 そして、パケットを再送してはいけません。
2.2.7. RENEW
2.2.7. 更新してください。
The RENEW message is used by a MADCAP client that wants to renew a multicast address lease, changing the lease time or start time.
RENEWメッセージはマルチキャストアドレスリースを更新したがっているMADCAPクライアントによって使用されます、リース時間か開始時刻を変えて。
The client unicasts the RENEW message to a MADCAP server. If the server can process the request successfully, it SHOULD unicast an ACK message to the client. Otherwise, it MUST generate and process an error in the manner described in section 2.6.
缶はサーバであるなら首尾よく要求を処理して、それはSHOULDユニキャストです。クライアントユニキャスト、MADCAPサーバへのRENEWメッセージ、クライアントへのACKメッセージ。 さもなければ、それは、セクション2.6で説明された方法で、誤りを生成して、処理しなければなりません。
The lease to be renewed is whichever one was allocated with a Lease Identifier option matching the one provided in the RENEW message.
更新されるべきリースはLease IdentifierオプションがRENEWメッセージに提供されたものに合っていて割り当てられたものです。
When a MADCAP client sends a RENEW message, it MAY include the Lease Time, Minimum Lease Time, Start Time, and Maximum Start Time options, describing the new lease it wants to receive. However, it need not include any of these options. If one of these options is not included, the server will provide the appropriate default (maximum available for Lease Time, no minimum for Minimum Lease Time, as soon as possible for Start Time, and no maximum for Maximum Start Time). The Current Time option MUST be included if the Start Time or Maximum Start Time options are included.
MADCAPクライアントがRENEWメッセージを送るとき、Lease Time、Minimum Lease Time、Start Time、およびMaximum Start Timeオプションを含むかもしれません、それが受けたがっている新しいリースについて説明して。 しかしながら、それはこれらのオプションのいずれも含む必要はありません。 これらのオプションの1つが含まれていないと、サーバが適切なデフォルトを提供する、(Lease Timeに利用可能な最大、Minimum Lease Timeのための最小限がない、できるだけ早さ、Start Timeにもかかわらず、Maximum Start Timeのための最大がありません) Start TimeかMaximum Start Timeオプションが含まれているなら、Current Timeオプションを含まなければなりません。
If a client sends a RENEW message and does not receive any ACK or NAK messages in response, the client SHOULD resend its RENEW message, as described in section 2.3.
クライアントがRENEWメッセージを送って、応答におけるどんなACKやNAKメッセージも受け取らないなら、クライアントSHOULDはRENEWメッセージを再送します、セクション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と共にこたえるか、または妥当な(実装依存する)遅れ[RESPONSE-DELAYがない]の中で応じないなら、クライアントは別のxidがあるRENEWメッセージを別のサーバに送るかもしれなくて、Server Mobilityの特徴がオリジナルのREQUESTメッセージとそれで使用されたならば、この特徴が別のサーバに送られたその後のRENEWメッセージに必要です。Server Mobilityの特徴に関する詳しい情報に関して、セクション2.13.1を見てください。 [RESPONSE-DELAYがありません]のためのRECOMMENDED値は60秒です。
Hanna, et al. Standards Track [Page 16] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[16ページ]。
2.2.8. RELEASE
2.2.8. リリース
The RELEASE message is used by a MADCAP client that wants to deallocate one or more multicast addresses before their lease expires.
RELEASEメッセージは彼らのリースが期限が切れる前に1つ以上のマルチキャストアドレスがdeallocateに欲しい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.
RELEASEがそれがアドレスを割り当てた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.
リリースされるべきリースはLease IdentifierオプションがRELEASEメッセージに提供されたものに合っていて割り当てられたものです。 ただ一つのリースに基づくアドレスの一部だけをリリースするのは可能ではありません。
If a client sends a RELEASE message and does not receive any ACK or NAK messages in response, the client SHOULD resend its RELEASE message, as described in section 2.3.
クライアントがRELEASEメッセージを送って、応答におけるどんなACKやNAKメッセージも受け取らないなら、クライアントSHOULDはRELEASEメッセージを再送します、セクション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と共にこたえるか、または妥当な(実装依存する)遅れ[RESPONSE-DELAYがない]の中で応じないなら、クライアントは別のxidがあるRELEASEメッセージを別のサーバに送るかもしれなくて、Server Mobilityの特徴がオリジナルのREQUESTメッセージとそれで使用されたならば、この特徴が別のサーバに送られたその後のRELEASEメッセージに必要です。Server Mobilityの特徴に関する詳しい情報に関して、セクション2.13.1を見てください。 [RESPONSE-DELAYがありません]のためのRECOMMENDED値は60秒です。
2.3. Retransmission
2.3. Retransmission
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クライアントはすべてのメッセージの再送に責任があります。 クライアントは「再-トランスミッション」の間の遅れを決定するために指数のbackoffアルゴリズムを取り入れる「再-トランスミッション」戦略を採用しなければなりません。 遅れ、retransmissions SHOULDの間では、クライアントとサーバの間のインターネットワークの特性に基づいて提供されるサーバから選ばれて、十分な時間、回答を考慮してください。
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
RECOMMENDEDアルゴリズムは、最初の「再-トランスミッション」の前で4 2番目の遅れを使用して、それぞれの連続した「再-トランスミッション」のために16秒と最大3個の「再-トランスミッション」の最大の遅れでこの遅れを倍にすることです。 時間(秒の)tで初期のトランスミッションを送って、応答を全く受けないなら、その後のトランスミッションがt+4、t+12、およびt+28にあるでしょうに。 t+60で応答を全く受けていないなら、クライアントが再送するのを止めて、別の行動を取るだろう、(誤りを登録するか、またはaを送るとしてのそのようなもの
Hanna, et al. Standards Track [Page 17] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[17ページ]。
message to another address.
別のアドレスへのメッセージ。
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.
クライアントはプロセスの進歩のしるしとして「再-トランスミッション」試みのしるしをユーザに供給するかもしれません。 クライアントは任意な点で「再-トランスミッション」を止めるかもしれません。
2.4. The Lease Identifier
2.4. リース識別子
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.
Lease Identifierオプションはそれぞれの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.
Lease Identifierの最初の八重奏はLease Identifierタイプです。 テーブル3はこのとき定義されているLease Identifierタイプとセクション2.4.1を記載します、そして、2.4に、.2はこれらのLease Identifierタイプについて説明します。
New MADCAP Lease Identifier types may only be defined by IETF Consensus, as described in section 5.
新しいMADCAP Lease Identifierタイプはセクション5で説明されるようにIETF Consensusによって定義されるだけであるかもしれません。
Lease Identifier Type Name
--------------------- ----
0 Random Lease Identifier
1 Address-Specific Lease Identifier
リース識別子型名--------------------- ---- 0 無作為のリース識別子1のアドレス特有のリース識別子
Table 3: MADCAP Lease Identifier Types
テーブル3: 向こう見ずなリース識別子タイプ
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サーバはLease Identifierを分析する必要はありません。 それ、SHOULDは単に不明瞭な識別子としてLease Identifierを使用します。(各リースに、それは、ユニークであるに違いありません)。 異なったLease Identifierタイプを定義する目的は既にグローバルにユニークなアドレスを持っているMADCAPクライアントがクライアント特有の識別子と共にこのアドレスを使用することによってLease Identifier衝突の可能性を避けるのを許容することです。 グローバルにユニークなアドレスSHOULDにLease Identifierを使用させない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分野次のセクションで説明されるように)を関連づけることに加えて、Lease Identifierは、RENEWかRELEASE要求がどのリースについて言及するかを決定するのに使用されます。 RENEWかLease Identifierが初期のREQUESTメッセージで使用されているRELEASEメッセージにLease Identifierを含んでいて、MADCAPサーバSHOULDは合っています。 Lease Identifierが合っていないなら、MADCAPサーバは、セクション2.6で説明された方法で、Lease Identifier Not Recognized誤りを生成して、処理しなければなりません。
Hanna, et al. Standards Track [Page 18] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[18ページ]。
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.
会議アプリケーションに、会議の参加者が会議に使用されるリースを変更するのを許容するのは望ましいかもしれません。 Shared Lease Identifier特徴コードは、この要件をサポートするのに使用されます。 リースを割り当てたとき、この特徴コードをクライアントが要求して、サーバで実装したなら、サーバSHOULDは、どんな認証要件も無効にして、Lease Identifierを知っているどんなクライアントもリースを変更するのを許容します。
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.
Security Considerations部で説明されるように、MADCAPセキュリティはマルチキャストルーティングインフラストラクチャにおける入場コントロールなしでものすごく役に立ちません。 しかしながら、Shared Lease Identifierの特徴を使用するとき、MADCAPセキュリティが望まれているなら、それを含むすべてのメッセージを暗号化することによって、Lease Identifierの秘密性を維持しなければなりません。 aを含んでいるA Lease Identifierが中古のコネがこの状況であったに違いないなら暗号で、乱数(長さにおける少なくとも8つの八重奏)を切望するので、Lease Identifierを推測するのは簡単ではありません。
2.4.1. Random Lease Identifier
2.4.1. 無作為のリース識別子
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.
Random Lease Identifierの最初の八重奏はLease Identifierタイプ(Random Lease Identifierを示す0)です。 これが来た後に、八重奏の系列、どのSHOULDがきちんとした乱数発生器から長い乱数(少なくとも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.
Random Lease Identifierは長さのどんなしるしも含んでいません。 これがLease Identifierに先行する長さの分野などの外部の手段で決定するかもしれないと思われます。
Lease ID
Type Random Number
+---------+-------------...
| 0 |
+---------+-------------...
IDタイプ乱数+を賃貸してください。---------+-------------... | 0 | +---------+-------------...
2.4.2. Address-Specific Lease Identifier
2.4.2. アドレス特有のリース識別子
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).
Address特有のLease Identifierの最初の八重奏はLease Identifierタイプ(Address特有のLease Identifierを示す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.
Address特有のLease Identifierは長さのどんなしるしも含んでいません。 これがLease Identifierに先行する長さの分野などの外部の手段で決定するかもしれないと思われます。
Hanna, et al. Standards Track [Page 19] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[19ページ]。
Lease ID Address Family Address Client-specific
Type Number Identifier
+---------+---------+---------+-----...-----+-----...-----+
| 1 | addrfamily | address | cli-spec id |
+---------+---------+---------+-----...-----+-----...-----+
リースIDアドレスファミリーは、クライアント特定のタイプ数の識別子が+であると扱います。---------+---------+---------+-----...-----+-----...-----+ | 1 | addrfamily| アドレス| cli-仕様イド| +---------+---------+---------+-----...-----+-----...-----+
2.5. Associating Client and Server Messages
2.5. クライアントとサーバメッセージを関連づけます。
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.
クライアントとサーバの間のメッセージはLease Identifierとxid分野を使用するお互いに関連しています。 クライアントがセクション2.1.4で説明されるようにxidを選ばなければならないので、xid、msgtype、およびLease Identifierの同じ組み合わせが[XID-REUSE-INTERVAL]の中の2つの異なったメッセージに使用されるのは(どれがそうしないかは自分たちの中で複数のクライアントの向こう側にさえ、交信します)、ありそうもないです。 クライアントかサーバによって送られた各メッセージにLease Identifierオプション、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).
クライアントは傑出しているトランザクションがないかどうか彼らがLease Identifierとxidに合っているのを保証する各入力メッセージのLease Identifierオプションとxid分野をチェックしなければなりません。 そうでなければ、メッセージを無視しなければなりません。 サーバはメッセージがないかどうか適切な関係を確立する各入力メッセージのLease Identifierオプションとxid分野をチェックしなければなりません。 文脈に、それが無効であるのでサーバがメッセージを処理できないなら、サーバは、Invalid Request誤りを生成して、処理しなければなりません、セクション2.6で説明されるように。 トランザクションは、マルチキャストアドレスを割り当てる試み(DISCOVERから成る、OFFER、REQUEST、ACK、およびNAKメッセージ)、借地契約を更新する試み(RENEWから成る、ACK、およびNAKメッセージ)、以前に割り当てられたマルチキャストアドレスをリリースする試み(RELEASEから成る、ACK、およびNAKメッセージ)、または設定パラメータを取得する試みであるかもしれません(GETINFO、ACK、およびNAKメッセージから成って)。
2.6. Processing Errors
2.6. 整理過程の誤差
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が適切なErrorオプションを含んでいて、サーバSHOULDは応じます。 しかしながら、サーバは、慢性の犯罪者を完全に無視すると決めるかもしれません。 メッセージがNAKであるかメッセージがNAK(例えば、メッセージには、誤り伝えられるか、または不正確なバージョン番号がある)であるかどうかは明確でないなら、サーバSHOULDがメッセージを無視します。 これはNAK輪を避けます。
If a MADCAP client encounters an error while processing a message, it MUST ignore the message.
MADCAPクライアントがメッセージを処理している間、誤りに遭遇するなら、それはメッセージを無視しなければなりません。
Hanna, et al. Standards Track [Page 20] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[20ページ]。
2.7. Multicast Scopes
2.7. マルチキャスト範囲
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.
RFC2365[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からアドレスを割り当てるのを試みる前に、クライアントSHOULDは、範囲がこのとき位置で有効であることを決定します。 MADCAPクライアントが事実上、管理範囲のセットを決定するのに使用するかもしれないいくつかのテクニック(範囲リスト)は以下の通りです。 MADCAP(Multicast Scope Listオプションを使用する)を通した手動の構成か構成。
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.
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.
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.
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.
2.8. Multicast TTL
2.8. Multicast TTL
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.
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.
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
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
Hanna, et al. Standards Track [Page 21] RFC 2730 MADCAP December 1999
Hanna, et al. Standards Track [Page 21] RFC 2730 MADCAP December 1999
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.
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.
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 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.
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.
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.
2.9. Locating MADCAP Servers
2.9. Locating MADCAP Servers
There are several ways for a MADCAP client to locate a MADCAP server. For instance, the client may be configured with an IP address.
There are several ways for a MADCAP client to locate a MADCAP server. For instance, the client may be configured with an IP address.
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.
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.
2.10. MADCAP Server Multicast Address
2.10. MADCAP Server Multicast Address
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.
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.
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.
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.
Hanna, et al. Standards Track [Page 22] RFC 2730 MADCAP December 1999
Hanna, et al. Standards Track [Page 22] RFC 2730 MADCAP December 1999
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.
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.
2.11. Going Beyond the Local Scope
2.11. Going Beyond the Local Scope
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.
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.
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.
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 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 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.
2.12. Clock Skew
2.12. Clock Skew
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.
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.
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.
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.
Hanna, et al. Standards Track [Page 23] RFC 2730 MADCAP December 1999
Hanna, et al. Standards Track [Page 23] RFC 2730 MADCAP December 1999
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).
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).
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.
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.
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 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.
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.
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.
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 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.
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
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
Hanna, et al. Standards Track [Page 24] RFC 2730 MADCAP December 1999
Hanna, et al. Standards Track [Page 24] RFC 2730 MADCAP December 1999
RECOMMENDED default is 30 minutes.
RECOMMENDED default is 30 minutes.
2.13. Optional Features
2.13. Optional Features
Each MADCAP client or server MAY implement one or more optional features. Optional features of MADCAP are identified with a two octet feature code.
Each MADCAP client or server MAY implement one or more optional features. Optional features of MADCAP are identified with a two octet feature code.
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.
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.
Table 4 lists the feature codes defined at this time and sections 2.13.1 and 2.13.2 describe how these features work.
Table 4 lists the feature codes defined at this time and sections 2.13.1 and 2.13.2 describe how these features work.
New MADCAP feature codes may only be defined by IETF Consensus, as described in section 5.
New MADCAP feature codes may only be defined by IETF Consensus, as described in section 5.
Feature Code Feature Name
------------ ------------
0 Server Mobility
1 Retry After
2 Shared Lease Identifier
Feature Code Feature Name ------------ ------------ 0 Server Mobility 1 Retry After 2 Shared Lease Identifier
Table 4: MADCAP Feature Codes
Table 4: MADCAP Feature Codes
2.13.1. Server Mobility
2.13.1. Server Mobility
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.
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.
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
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
Hanna, et al. Standards Track [Page 25] RFC 2730 MADCAP December 1999
Hanna, et al. Standards Track [Page 25] RFC 2730 MADCAP December 1999
an Option Request List option that includes the Feature List option code.
an Option Request List option that includes the Feature List option code.
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.
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.
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.
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.
2.13.2. Retry After
2.13.2. Retry After
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.
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.
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.
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.
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.
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.
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.
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.
Hanna, et al. Standards Track [Page 26] RFC 2730 MADCAP December 1999
Hanna, et al. Standards Track [Page 26] RFC 2730 MADCAP December 1999
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.
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.
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.
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.
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.
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.
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.
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.
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.
2.13.3. Shared Lease Identifier
2.13.3. Shared Lease Identifier
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.
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.
Hanna, et al. Standards Track [Page 27] RFC 2730 MADCAP December 1999
Hanna, et al. Standards Track [Page 27] RFC 2730 MADCAP December 1999
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.
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.
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.
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.
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.
3. MADCAP Options
3. MADCAP Options
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.
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.
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.
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.
Hanna, et al. Standards Track [Page 28] RFC 2730 MADCAP December 1999
Hanna, et al. Standards Track [Page 28] RFC 2730 MADCAP December 1999
Table 5 summarizes which options are allowed with each message type.
Table 5 summarizes which options are allowed with each message type.
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 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 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
Hanna, et al. Standards Track [Page 29] RFC 2730 MADCAP December 1999
Hanna, et al. Standards Track [Page 29] RFC 2730 MADCAP December 1999
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 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 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
Hanna, et al. Standards Track [Page 30] RFC 2730 MADCAP December 1999
Hanna, et al. Standards Track [Page 30] RFC 2730 MADCAP December 1999
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 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
オプションNAK------ --- リース時間必須NOTサーバ識別子必須リース識別子必須マルチキャスト範囲は現在の最小の必須の最大の開始時刻必須NOT誤りNOT時間必須NOT特徴リスト5月の再試行時間必須NOTリース時間必須NOT必須をアドレスの必須NOT番号が、必須が、言語必須NOTマルチキャスト範囲リストがリストアップされてはいけないよう要求しなかったよう要求したアドレスの範囲の要求リスト必須NOT開始時刻にゆだねてはいけません。
Table 5: Options allowed in MADCAP messages
テーブル5: MADCAPメッセージに許容されたオプション
3.1. End
3.1. 終わり
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.
Endオプションはオプション分野に有効な情報の終わりを示します。 それぞれのMADCAPメッセージにオプション分野の端にこのオプションを含まなければなりません。
Hanna, et al. Standards Track [Page 31] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[31ページ]。
The code for this option is 0, and its length is 0.
このオプションのためのコードは0です、そして、長さは0です。
Code Len
+-----+-----+-----+-----+
| 0 | 0 |
+-----+-----+-----+-----+
コードレン+-----+-----+-----+-----+ | 0 | 0 | +-----+-----+-----+-----+
3.2. Lease Time
3.2. リース時間
This option is used in a client request (DISCOVER, REQUEST, or RENEW) to allow the client to request a lease time for the multicast address. In a server reply (OFFER or ACK), a MADCAP server uses this option to specify the lease time it is willing to offer.
このオプションはマルチキャストアドレスにクライアントがリース時間を要求するのを許容するというクライアント要求(DISCOVER、REQUEST、またはRENEW)で使用されます。 サーバ回答(OFFERかACK)では、MADCAPサーバは、それが提供しても構わないと思っているリース時間を指定するのにこのオプションを使用します。
The time is in units of seconds, and is specified as a 32-bit unsigned integer.
時間は、ユニットの秒に、あって、32ビットの符号のない整数として指定されます。
The code for this option is 1, and its length is 4.
このオプションのためのコードは1です、そして、長さは4です。
Code Len Lease Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
コードレンリース時間+-----+-----+-----+-----+-----+-----+-----+-----+ | 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.
(IANAによって定義されるように、[10])で定義されたものを含んでいるのは最初に保存されます、アドレスがあとに続いていて。このオプションはMADCAPサーバのIPアドレスを含んでいます。2八重奏はファミリーナンバを扱います。 このアドレスのためのアドレスファミリーは、別のファミリーのアドレスでサーバとコミュニケートしている間、1つのファミリーからのアドレスを割り当てることができるように固定ヘッダーの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アドレスがメッセージを送るServer Identifierオプションを含まなければなりません。
MADCAP clients MUST include a Server Identifier option in multicast REQUEST messages in order to indicate which OFFER message has been accepted.
MADCAPクライアントは、どのOFFERメッセージが受け入れられたかを示すためにマルチキャストREQUESTメッセージでServer Identifierオプションを入れなければなりません。
The code for this option is 2, and its minimum length is 3.
このオプションのためのコードは2です、そして、最小の長さは3です。
Code Len Address Family Address
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 2 | n | family | a1 | ... |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
レンアドレスファミリーが+であると扱うコード-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 2 | n| ファミリー| a1| ... | +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Hanna, et al. Standards Track [Page 32] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[32ページ]。
3.4. Lease Identifier
3.4. リース識別子
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 | ...
+-----+-----+-----+-----+-----+-----+---
コードレンリース識別子+-----+-----+-----+-----+-----+-----+--- | 3 | n| i1| i2| ... +-----+-----+-----+-----+-----+-----+---
3.5. Multicast Scope
3.5. マルチキャスト範囲
The multicast scope option is used by the client to indicate the requested multicast scope in a DISCOVER or REQUEST message. It is also used by the MADCAP server to indicate the scope of an assigned address.
マルチキャスト範囲オプションは、DISCOVERかREQUESTメッセージで要求されたマルチキャスト範囲を示すのにクライアントによって使用されます。 また、それはMADCAPサーバによって使用されて、割り当てられたアドレスの範囲を示します。
The client may obtain the scope list through the Multicast Scope List option or using some other means. The Scope ID is the first multicast address in the scope. The address family of the Scope ID is determined by the addrfamily field in the fixed header.
クライアントは、Multicast Scope Listオプションかある他の手段を使用することで範囲リストを得るかもしれません。 Scope IDは範囲で最初のマルチキャストアドレスです。 Scope IDのアドレスファミリーは固定ヘッダーのaddrfamily分野のそばで決定しています。
The code for this option is 4, and its minimum length is 1.
このオプションのためのコードは4です、そして、最小の長さは1です。
Code Len Scope ID
+-----+-----+-----+-----+-----+-----
| 4 | n | i1 | ...
+-----+-----+-----+-----+-----+-----
コードレン範囲ID+-----+-----+-----+-----+-----+----- | 4 | n| i1| ... +-----+-----+-----+-----+-----+-----
3.6. Option Request List
3.6. オプション要求リスト
This option is used by a MADCAP client in an GETINFO message to request that certain options be included in the server's ACK response. The server SHOULD try to include the specified options in its response, but is not required to do so.
このオプションはあるオプションがサーバのACK応答に含まれているよう要求するGETINFOメッセージでMADCAPクライアントによって使用されます。 SHOULDが応答における指定されたオプションを含んでいようとしますが、したがってそうしている必要はないサーバ。
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 |
+-----+-----+-----+-----+-----+-----+---...
Codeレンはオプション+を要求しました。-----+-----+-----+-----+-----+-----+---... | 5 | n| Option1| +-----+-----+-----+-----+-----+-----+---...
Hanna, et al. Standards Track [Page 33] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[33ページ]。
3.7. Start Time
3.7. 開始時刻
The Start Time option specifies the starting time for a multicast address lease.
Start Timeオプションはマルチキャストアドレスリースのための始動時を指定します。
A client may include this option in a DISCOVER, RENEW, or REQUEST message to request a multicast address for use at a future time. A server may include this option in an OFFER message or in an ACK in response to REQUEST or RENEW message to indicate that a lease has been granted which starts at a future time.
クライアントはDISCOVER、RENEW、または将来の時間に使用のためのマルチキャストアドレスを要求するREQUESTメッセージでこのオプションを入れるかもしれません。 サーバはOFFERメッセージかACKにREQUESTかリースが承諾されたのを示す将来の時間に始動するRENEWメッセージに対応してこのオプションを含むかもしれません。
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.
Start Timeオプションが存在しているなら、IP Address Lease TimeオプションはStart Timeオプション価値で始まるリースの持続時間を指定します。
If the Start Time option is present, the Current Time option MUST also be present, as described in section 2.12.
また、Start Timeオプションが存在しているなら、Current Timeオプションもセクション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.
時間的価値は協定世界時0時0分(1970年1月1日)以来の秒数を与えるネットワークバイトオーダーで32ビットの未署名の整数です。 10進2208988800を加えることによって、NTPタイムスタンプにこれを変換できます。 形式が2106年まで包装しない今回。
The code for this option is 6 and the length is 4.
このオプションのためのコードは6です、そして、長さは4です。
Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 6 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
コードレン時間+-----+-----+-----+-----+-----+-----+-----+-----+ | 6 | 4 | t1| t2| t3| t4| +-----+-----+-----+-----+-----+-----+-----+-----+
3.8. Number of Addresses Requested
3.8. 要求されたアドレスの数
This option specifies the minimum and desired number of addresses requested by the client. It is only used in DISCOVER and REQUEST messages and is only sent by the client.
このオプションはクライアントによって要求されたアドレスの最小の、そして、必要な数を指定します。 それは、DISCOVERとREQUESTメッセージで使用されるだけであり、クライアントによって送られるだけです。
The minimum and desired number of addresses requested are unsigned 16 bit integers in network byte order. The minimum MUST be less than or equal to the desired number. If a message is received where this is not the case, the MADCAP server MUST generate and process an Invalid Request error in the manner described in section 2.6.
要求されたアドレスの最小の、そして、必要な数はネットワークバイトオーダーで16ビットの未署名の整数です。 最小限は必要なより数以下であるに違いありません。 これがそうでないところにメッセージを受け取るなら、MADCAPサーバは、セクション2.6で説明された方法で、Invalid Request誤りを生成して、処理しなければなりません。
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
クライアントは、あらゆるアドレスのためにプロトコルを繰り返すか、または同時にこのオプションでいくつかのアドレスを要求することによって、1つ以上のアドレスを得るかもしれません。 クライアントが、1つのアドレスだけ、このオプションSHOULD NOTが含まれているよう要求しているとき。 MADCAPサーバ
Hanna, et al. Standards Track [Page 34] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[34ページ]。
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.
このオプションを含んでいるとどんなOFFERやACK応答でも、アドレスの最小の、そして、必要な数の間に含まれなければならないDISCOVERかREQUESTパケットを受けます。
The code for this option is 7 and the length is 4.
このオプションのためのコードは7です、そして、長さは4です。
Code Len Minimum Desired
+-----+-----+-----+-----+-----+-----+-----+-----+
| 7 | 4 | min | desired |
+-----+-----+-----+-----+-----+-----+-----+-----+
コードレン最小限は+を望んでいました。-----+-----+-----+-----+-----+-----+-----+-----+ | 7 | 4 | 分| 望まれています。| +-----+-----+-----+-----+-----+-----+-----+-----+
3.9. Requested Language
3.9. 要求された言語
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メッセージに含まれているだけです。 それはRFC1766[6]言語タグです。 Multicast Scope Listオプションの定義で、より詳しくゾーン名に関してこのタグを扱う適切な方法について議論します。
The code for this option is 8 and the minimum length is 0.
このオプションのためのコードは8です、そして、最小の長さは0です。
Code Len Language Tag
+-----+-----+-----+-----+-----+-...-+-----+
| 8 | n | L1 | | Ln |
+-----+-----+-----+-----+-----+-...-+-----+
コードレン言語タグ+-----+-----+-----+-----+-----+-...-+-----+ | 8 | n| L1| | Ln| +-----+-----+-----+-----+-----+-...-+-----+
3.10. Multicast Scope List
3.10. マルチキャスト範囲リスト
This option is sent by the server in an ACK message in response to an GETINFO message sent by the client.
ACKメッセージのサーバはクライアントによって送られたGETINFOメッセージに対応してこのオプションを送ります。
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メッセージでRequested Languageオプションを入れなかったなら、MADCAPサーバSHOULDはすべてのゾーン名を各ゾーンに返します。 クライアントがGETINFOメッセージでRequested Languageオプションを入れたなら、MADCAPサーバは各ゾーンあたり1つ未満のゾーン名を返さなければなりません。 各ゾーンに、MADCAPサーバSHOULDは最初に、要求された言語タグに合っているゾーン名を探します(大文字と小文字を区別しないASCII比較を使用して)。 何か名前が合っているなら、それらの1つを返すべきです。 さもなければ、MADCAPサーバSHOULDは、戻るために別のゾーン名を選びます(いずれか定義されるなら)。 それ、SHOULDはどんな名前も必要な言語で利用可能でないなら使用されるためにマークされるゾーン名に優先を与えます。
Hanna, et al. Standards Track [Page 35] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[35ページ]。
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 |
+-----+-----+-----+-----+-----+-----+-...-+-----+
コードレンカウント範囲リスト+-----+-----+-----+-----+-----+-----+-...-+-----+ | 9 | p| m| L1| | Lm| +-----+-----+-----+-----+-----+-----+-...-+-----+
The scope list is a list of m tuples, where each tuple is of the form:
範囲リストはm tuplesのリストです:(そこでは、各tupleがフォームのものです)。
Scope ID Last Address TTL Name Encoded Name List
Count
+---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+
| ... ID ... | ... Last ... | T | n | EN1 | | ENn |
+---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+
最後の範囲IDアドレスTTLはコード化された人名簿カウントを+と命名します。---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+ | ... ID… | ... 最終… | 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.
Scope IDが範囲で最初のマルチキャストアドレスであるところでは、Last Addressが範囲で最後のマルチキャストアドレスです、そして、TTLが範囲のマルチキャストアドレスのためのマルチキャストTTL価値です、そして、Name Countがこのゾーン(ゼロであるかもしれない)へのコード化された名前の数です。 Scope IDとLast Addressのアドレスファミリーは固定ヘッダーの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 |
+-----+-----+-----+-...-+-----+-----+-----+-...-+-----+
ラング言語タグ名前名前旗を長さの長さ+と命名してください。-----+-----+-----+-...-+-----+-----+-----+-...-+-----+ | 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.
ラングLengthが八重奏(ゼロであるはずがない)で、Name Flagsが旗が以下で定義されている旗の分野であることのLanguage Tagの長さである、Language Tagはゾーン名の用語を示す言語タグです。([6])で説明されるように、Name Lengthは八重奏(ゼロであるはずがない)で、Nameの長さであり、Nameは付与という名前を範囲ゾーンに示す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.
Name Flags分野の高いビットは以下の名前が名前でないなら使用されるならセットが必要な言語で利用可能であるということです。 さもなければ、このビットはきれいにされます。 八重奏SHOULDにおけるすべての残っているビットをゼロに設定されて、無視しなければなりません。
Hanna, et al. Standards Track [Page 36] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[36ページ]。
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.
リストにおけるエントリーのScope IDは、ユニークであって、範囲SHOULDであるに違いありません。最も小ささ(位相的に話すなら)から最も大きくなるまで記載されてください。 これで、通常、範囲が同次を保っていて一貫したユーザーインタフェースを表示するのは、より簡単になります。 しかしながら、範囲は厳密に入れ子にされないかもしれません。 この状況に、厳しい最も小さいのから最も大きくなるまでの注文がありません、そして、サーバは範囲リストを注文するのに別のテクニックを使用しなければなりません。
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 |
+-----+-----+-----+-----+-----+...
コードレンカウント+-----+-----+-----+-----+-----+... | 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 |
+---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
最後の範囲IDアドレスTTLは名前ラング言語カウント旗を長さのタグ+と命名します。---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+... |239|192| 0 | 0 |239|195|255|255|10 | 1 | 128 | 2 | アン| +---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
Name
Length Name
+------+--+--+-...-+--+--+...
| 15 | Inside abcd.com |
+------+--+--+-...-+--+--+...
長さの名を+に挙げてください。------+--+--+-...-+--+--+... | 15 | 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 |
+---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
最後の範囲IDアドレスTTLは名前ラング言語カウント旗を長さのタグ+と命名します。---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+... |224| 0 | 1 | 0 |238|255|255|255|16 | 1 | 128 | 2 | アン| +---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
Name
Length Name
+------+--...--+
| 5 | world |
+------+--...--+
長さの名を+に挙げてください。------+--...--+ | 5 | 世界| +------+--...--+
Hanna, et al. Standards Track [Page 37] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[37ページ]。
3.11. List of Address Ranges
3.11. アドレスのリストは及びます。
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 |
+-----+-----+-----+-----+-----+-----+-...-+-----+
コードレンアドレス範囲リスト+-----+-----+-----+-----+-----+-----+-...-+-----+ | 10 | n| L1| L2| | Ln| +-----+-----+-----+-----+-----+-----+-...-+-----+
where the Address Range List is of the following format.
Address Range Listが以下の形式のものであるところ。
StartAddress1 BlockSize1 StartAddress2 BlockSize2 ...
+---+---+---+---+---+---+---+---+---+---+---+---+--...--+
| ... S1 ... |B11|B12| ... S2 ... |B21|B22| |
+---+---+---+---+---+---+---+---+---+---+---+---+--...--+
StartAddress1 BlockSize1 StartAddress2 BlockSize2… +---+---+---+---+---+---+---+---+---+---+---+---+--...--+ | ... S1… |B11|B12| ... S2… |B21|B22| | +---+---+---+---+---+---+---+---+---+---+---+---+--...--+
3.12. Current Time
3.12. 現在の時間
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.
このオプションは、送付者が、考える現在の時間が何であるかを言い表すのに使用されます。 これは時計斜行を検出することの役に立ちます。 Start TimeかMaximum Start Timeオプションが使用されているなら、このオプションを含まなければなりません、セクション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.
時間的価値は協定世界時0時0分(1970年1月1日)以来の秒数を与えるネットワークバイトオーダーで32ビットの未署名の整数です。 10進2208988800を加えることによって、NTP[4]タイムスタンプにこれを変換できます。 形式が2106年まで包装しない今回。
The code for this option is 11 and the length is 4.
このオプションのためのコードは11です、そして、長さは4です。
Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 11 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
コードレン時間+-----+-----+-----+-----+-----+-----+-----+-----+ | 11 | 4 | t1| t2| t3| t4| +-----+-----+-----+-----+-----+-----+-----+-----+
Hanna, et al. Standards Track [Page 38] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[38ページ]。
3.13. Feature List
3.13. 特徴リスト
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八重奏特徴コードと同一視されています。 新しいMADCAP特徴コードはセクション5で説明されるようにIETF Consensusによって定義されるだけであるかもしれません。
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.
Feature 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クライアントがメッセージでFeature Listオプションを入れるなら、リストのどれかにおける特徴を含むかもしれません: サポートされて、要求されていて、必要です。 MADCAPサーバがFeature Listオプションを含むメッセージを受け取って、必要なリストにおける特徴のすべてをサポートしないなら、それは、セクション2.6で説明された方法で、Required Feature Not Supported誤りを生成して、処理しなければなりません。 サーバが必要なリストにおける特徴のすべてをサポートするなら、それはこのメッセージのために適宜それらを実装しなければなりません。 それ、SHOULDは要求されたリストにおける特徴を実装しようとして、それはサポートしているリストにおける特徴のいずれも実装するかもしれません。 クライアントのメッセージにオプションを含んでいて(クライアントがメッセージでFeature Listオプションを入れないなら)、オプション機能(Retry Afterなどの)がFeature Listのどんな部分にも含まれていないなら、サーバは応答におけるその特徴を使用してはいけません。
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サーバがFeature Listオプションを含んでいるクライアントのメッセージに反応するなら、サーバはそれがサポートする特徴をリストアップするサポートしている特徴リスト、それがこのメッセージ(クライアントのFeature Listオプションのサポートしている特徴リストに含まなければならない)に応じる際に実装した特徴をリストアップする必要な特徴リスト、および空の要求された特徴リストがあるFeature Listオプションを含まなければなりません。
Hanna, et al. Standards Track [Page 39] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[39ページ]。
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 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
要求されていて、レンがサポートしたコードは+を必要としました。-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 12 | n| FL1| FL2| FL3| +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
where each of the Feature Lists is of the following format:
それぞれのFeature Listsが以下のものであるところでは、以下をフォーマットしてください。
Feature Feature Feature
Count Code 1 Code m
+-----+-----+-----+-----+-...-+-----+-----+
| m | FC1 | | FCm |
+-----+-----+-----+-----+-...-+-----+-----+
特徴特徴特徴カウントコード1はm+をコード化します。-----+-----+-----+-----+-...-+-----+-----+ | m| FC1| | FCm| +-----+-----+-----+-----+-...-+-----+-----+
3.14. Retry Time
3.14. 再試行時間
The Retry Time option specifies the time at which a client should retry a REQUEST or RENEW message when using the Retry After feature.
Retry TimeオプションはRetry Afterの特徴を使用するクライアントがREQUESTかRENEWメッセージを再試行するべきである時を指定します。
This option should only be sent by a MADCAP server in an ACK when responding to a REQUEST or RENEW message that includes the Retry After feature in the supported, requested, or required list. For more discussion of Retry After, see section 2.13.2.
サポートしているか、要求されたか、必要なリストにおけるRetry Afterの特徴を含んでいるREQUESTかRENEWメッセージに応じるときだけ、ACKのMADCAPサーバはこのオプションを送るべきです。 Retry Afterの、より多くの議論に関しては、セクション2.13.2を見てください。
If the Retry Time option is present, the Current Time option MUST also be present.
また、Retry Timeオプションが存在しているなら、Current Timeオプションも存在していなければなりません。
The time value is an unsigned 32 bit integer in network byte order giving the number of seconds since 00:00 UTC, 1st January 1970. This can be converted to an NTP timestamp by adding decimal 2208988800. This time format will not wrap until the year 2106.
時間的価値は協定世界時0時0分(1970年1月1日)以来の秒数を与えるネットワークバイトオーダーで32ビットの未署名の整数です。 10進2208988800を加えることによって、NTPタイムスタンプにこれを変換できます。 形式が2106年まで包装しない今回。
The code for this option is 13 and the length is 4.
このオプションのためのコードは13です、そして、長さは4です。
Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 13 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
コードレン時間+-----+-----+-----+-----+-----+-----+-----+-----+ | 13 | 4 | t1| t2| t3| t4| +-----+-----+-----+-----+-----+-----+-----+-----+
3.15. Minimum Lease Time
3.15. 最小のリース時間
This option is used in a client request (DISCOVER, REQUEST, or RENEW) to allow the client to specify a minimum lease time for the multicast address. If a server cannot meet this minimum lease time, it MUST generate and process a Valid Request Could Not Be Completed error in the manner described in section 2.6.
このオプションはマルチキャストアドレスにクライアントが最小のリース時間を指定するのを許容するというクライアント要求(DISCOVER、REQUEST、またはRENEW)で使用されます。 サーバがこの最小のリース時間を達成できないなら、それは、セクション2.6で説明された方法で、Valid Request Could Not Be Completed誤りを生成して、処理しなければなりません。
Hanna, et al. Standards Track [Page 40] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[40ページ]。
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 |
+-----+-----+-----+-----+-----+-----+-----+-----+
コードレンリース時間+-----+-----+-----+-----+-----+-----+-----+-----+ | 14 | 4 | t1| t2| t3| t4| +-----+-----+-----+-----+-----+-----+-----+-----+
3.16. Maximum Start Time
3.16. 最大の開始時刻
The Maximum Start Time option specifies the latest starting time that the client is willing to accept for a multicast address lease.
Maximum Start Timeオプションはクライアントが、マルチキャストアドレスリースのために受け入れても構わないと思う最新の始動時を指定します。
A client may include this option in a DISCOVER, RENEW, or REQUEST message to specify that it does not want to receive a lease with a starting time later than the specified value. If a server cannot meet this maximum start time, it MUST generate and process a Valid Request Could Not Be Completed error in the manner described in section 2.6.
クライアントはDISCOVER、RENEW、または規定値より遅く始動時でリースを受けたがっていないと指定するREQUESTメッセージでこのオプションを入れるかもしれません。 サーバがこの最大の開始時刻に間に合うことができないなら、それは、セクション2.6で説明された方法で、Valid Request Could Not Be Completed誤りを生成して、処理しなければなりません。
If the Maximum Start Time option is present, the Current Time option MUST also be present, as described in section 2.12.
また、Maximum Start Timeオプションが存在しているなら、Current Timeオプションも存在していなければなりません、セクション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.
時間的価値は協定世界時0時0分(1970年1月1日)以来の秒数を与えるネットワークバイトオーダーで32ビットの未署名の整数です。 10進2208988800を加えることによって、NTPタイムスタンプにこれを変換できます。 形式が2106年まで包装しない今回。
The code for this option is 15 and the length is 4.
このオプションのためのコードは15です、そして、長さは4です。
Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 15 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
コードレン時間+-----+-----+-----+-----+-----+-----+-----+-----+ | 15 | 4 | t1| t2| t3| t4| +-----+-----+-----+-----+-----+-----+-----+-----+
3.17. Error
3.17. 誤り
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メッセージにErrorオプションを含まなければなりません。
The first two octets of an Error option contain a MADCAP error code. Several MADCAP error codes are defined later in this section. New MADCAP error codes may only be defined by IETF Consensus, as described in section 5.
Errorオプションの最初の2つの八重奏がMADCAPエラーコードを含んでいます。 いくつかのMADCAPエラーコードが後でこのセクションで定義されます。 新しいMADCAPエラーコードはセクション5で説明されるようにIETF Consensusによって定義されるだけであるかもしれません。
Hanna, et al. Standards Track [Page 41] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[41ページ]。
Any remaining octets in the Error option contain extra data about the error. The format of this data depends on the error code. The definition of a MADCAP error code must include a definition of the extra data to be included with that error code.
Errorオプションにおけるどんな残っている八重奏も誤りに関する付加的なデータを含んでいます。 このデータの形式はエラーコードに依存します。 MADCAPエラーコードの定義は、そのエラーコードで含まれるように付加的なデータの定義を含まなければなりません。
A client that receives a NAK message containing an Error option MAY log or display a message indicating the error code and extra data received. The client MUST NOT retransmit a message once a NAK response to that message has been received. The client MAY adjust the message to correct the error and send the corrected message or send a message to a different server.
Errorオプションを含む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
+-----+-----+-----+-----+-----+-----+-----+-----+ ...
レンのエラーコードの付加的なデータ+をコード化してください。-----+-----+-----+-----+-----+-----+-----+-----+ ... | 16 | n| ecode| d1 d2+-----+-----+-----+-----+-----+-----+-----+-----+ ...
3.17.1. Valid Request Could Not Be Completed
3.17.1. 有効な要求は終了できませんでした。
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の値は、問題が特定のオプションと共になかったのを示します。
3.17.2. Invalid Request
3.17.2. 無効の要求
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の値は、問題が特定のオプションと共になかったのを示します。
3.17.3. Excessive Clock Skew
3.17.3. 過度の時計斜行
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八重奏時間的価値から成ります、協定世界時0時0分以来の秒数を与えるネットワークバイトオーダーにおける32ビットの未署名の整数、1970年1月1日。 10進2208988800を加えることによって、NTPタイムスタンプにこれを変換できます。 形式が2106年まで包装しない今回。
Hanna, et al. Standards Track [Page 42] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[42ページ]。
3.17.4. Lease Identifier Not Recognized
3.17.4. 認識されなかったリース識別子
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は、Lease Identifierが認識されなかったのを(通常RENEWかRELEASEメッセージに対応して)示します。 どんな付加的なデータもありません。
3.17.5. Required Feature Not Supported
3.17.5. サポートされなかった必要な特徴
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は、Feature Listオプションの必要なリストに少なくとも1つの特徴を含んでいるのがサポートされないのを示します。 付加的なデータは必要なリストのサポートされない特徴コードのリストを含んでいます。
3.17.6. Experimental Use
3.17.6. 実験用
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は実験用のために予約されます。 これらのエラーコードで付加的なデータを含む書式は定義されません。
4. Security Considerations
4. セキュリティ問題
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
凶暴なMADCAPサーバ(誤構成されたサーバの、そして、意図的な)から守るために、ある状況におけるクライアントはサーバを認証したがっています。監査か簿記目的のために、同様に、サーバはクライアントを認証したがっているかもしれません。 そのうえ、いくつかの場合、サーバは、システムかユーザに割り当てられるアドレスの数を制限するために適所に、ある方針を持っているかもしれません。 よく振る舞いましたが、ナイーブなユーザかクライアントが多くのアドレスを要求して、したがって、うっかり他のユーザかシステムに影響を与えるとき、多くの価値がこの特徴にあります。したがって、管理者はクライアント識別に基づくコントロールの数量限定を出したがっているかもしれません。 クライアント識別は基づくことができました。
Hanna, et al. Standards Track [Page 43] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[43ページ]。
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.
システムかユーザアイデンティティに関して。 ほとんどの実用的な状況で、システムの同定は十分であるだろう、時には、特にマルチユーザシステムの場合にしかしながら、ユーザ登録名は重要な役割を果たすでしょう。 したがって、ユーザ登録名に基づく認証能力は望ましいかもしれません。 いつものように、データ保全は強い要件です、そして、保護されないなら、サービス不能攻撃を含むことにおける多くの問題を引き起こすことができます。
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メッセージに基づいている)特定のユーザが、ある期間と範囲への多くのアドレスを要求したのを知っているなら、彼は、そのような要求の後ろで目的を推測して、攻撃を狙うことができるかもしれません。 Shared Lease Identifierの特徴が使用されているとき、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 SHOULD、セキュリティは強い要件です。したがって、いつ、MADCAPプロトコルに関するすべてのユニキャストメッセージを保護するには、使用されてくださいか。 GETINFO MUSTを除いて、IPSECのベースのセキュリティが使用中で、すべてマルチキャストパケットであるときにはMADCAPサーバによって下げられてください。IPSECの一般的な実装は、システムの同定の形における識別をクライアントにサポートして、ユーザ登録名をサポートしません。 しかしながら、望まれていると、適切なAPIのものがあるIPSECはユーザ登録名をサポートしなければならないかもしれません。
5. IANA Considerations
5. IANA問題
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 Lease Identifierタイプ、MADCAPの特徴、およびMADCAPエラーコード)を定義します。 これらの数の空間のすべてに関しては、ある値はこの仕様に基づき定義されます。 新しい値は[7]で説明されるようにIETF Consensusによって定義されるだけであるかもしれません。 基本的に、これは、それらがIESGによって承認されたRFCsによって定義されることを意味します。
Hanna, et al. Standards Track [Page 44] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[44ページ]。
6. Acknowledgments
6. 承認
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、スティーブ・デアリング、ピーター・フォード、マーク・ハンドレー、ヴァン・ジェーコブソン、デヴィッド・オラン、トーマス・プフェニング、デーヴ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]に基づいています。 このドキュメントの作者はこれらの前の作品の作者に感謝したがっています。 どんな誤りも本書では唯一このドキュメントの作者のせいです。
7. References
7. 参照
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[1]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[2] アレクサンダーとS.とR.Droms、「DHCPオプションとBOOTPベンダー拡大」、RFC2132、1997年3月。
[3] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998.
[3] マイヤー、D.、「行政上見られたIPマルチキャスト」、BCP23、RFC2365、1998年7月。
[4] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation and Analysis", RFC 1305, March 1992.
[4] 工場、D.、「ネットワーク時間は仕様、実装、および分析について議定書の中で述べ(バージョン3)」RFC1305、1992年3月。
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[5]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
[6] Alvestrand, H., "Tags for the Identification of Languages", RFC
1766, March 1995.
Alvestrand(H.)が「言語の識別のためにタグ付けをする」[6]、RFC1766、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[8] Atkinson, R. and S. Kent, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[8] アトキンソンとR.とS.ケント、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[9] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[10] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[11] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989.
[11] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
Hanna, et al. Standards Track [Page 45] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[45ページ]。
[12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[12] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[13] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[13]HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[14] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[14]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
8. Authors' Addresses
8. 作者のアドレス
Stephen R. Hanna Sun Microsystems, Inc. One Network Drive Burlington, MA 01803
スティーブンR.ハンナサン・マイクロシステムズ・インク1ネットワークドライブバーリントン、MA 01803
Phone: +1.781.442.0166 EMail: steve.hanna@sun.com
以下に電話をしてください。 +1.781 .442 .0166 メール: steve.hanna@sun.com
Baiju V. Patel Intel Corp. Mail Stop: AG2-201 5200 NE Elam Young Parkway Hillsboro, OR 97124
Baiju対パテルインテル社Mailは止まります: AG2-201 5200Neイーラム・ヤング・Parkwayヒースボロー、または97124
Phone: 503 696 8192 EMail: baiju.v.patel@intel.com
以下に電話をしてください。 8192年の503 696メール: baiju.v.patel@intel.com
Munil Shah Microsoft Corporation One Microsoft Way Redmond, WA 98052
Munilシャーマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: 425 703 3924 EMail: munils@microsoft.com
以下に電話をしてください。 3924年の425 703メール: munils@microsoft.com
Hanna, et al. Standards Track [Page 46] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[46ページ]。
APPENDIX A: Examples
付録A: 例
This appendix includes several examples of typical MADCAP protocol exchanges.
この付録は典型的なMADCAPプロトコル交換に関するいくつかの例を含んでいます。
1. Multicast Scope List Discovery
1. マルチキャスト範囲リスト発見
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 Local Scopeに対応するMADCAP Server Multicast AddressにGETINFOパケットを始めます。 このパケットはLease Identifierオプション、Multicast Scope Listオプションコード、およびストリング「アン」を含むRequested Languageオプションを含むOption Request Listを含んでいます、クライアントが英語を好むために構成されるので。
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").
2つのMADCAPサーバが、メッセージをACKに送ることによって、反応します。 これらのACKメッセージは範囲(最も密接に言語タグ「アン」に合っているもの)あたり1つの名前があるLease Identifierオプション、クライアントによって供給されたxid、サーバのServer Identifier、およびMulticast Scope Listを含んでいます。
The following figure illustrates this exchange.
以下の図はこの交換を例証します。
Server Client Server
v v v
| | |
| | |
| _____________/|\_____________ |
|/ GETINFO | GETINFO \|
| | |
| | |
|\ | ____________/|
| \_________ | / ACK |
| ACK \ |/ |
| \ | |
| | |
v v v
サーバClient Server v対v| | | | | | | _____________/|\_____________ | |/GETINFO| GETINFO\| | | | | | | |\ | ____________/| | \_________ | /ACK| | ACK\|/ | | \ | | | | | v vに対して
Figure 2: Timeline diagram of messages exchanged
in Multicast Scope List Discovery example
図2: Multicast Scope Listディスカバリーの例で交換されたメッセージのスケジュールダイヤグラム
2. Multicast Discovery and Address Allocation
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時間使用のためのグローバルな範囲からマルチキャストアドレスを割り当てたがっています。
Hanna, et al. Standards Track [Page 47] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[47ページ]。
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 Local Scopeに関連しているMADCAP Server Multicast AddressにDISCOVERパケットを始めます。 このパケットはLease Time、Lease Identifier、およびMulticast Scopeオプションを含んでいます。
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パケットを受けて、この要望に応じることができるどんなサーバも、クライアントのために一時アドレスを予約します、そして、ユニキャストはクライアントへのOFFERパケットを予約します。 これらのパケットはLease Time、Server Identifier、Lease Identifier、およびMulticast Scopeオプションを含んでいます。
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 Server Multicast Addressへのクライアントマルチキャストa REQUESTパケットの後に。 このパケットは、DISCOVERパケットにオプションを含むすべてを含んでいますが、Server Identifierオプションをまた含んでいます、それが要求のためにどのサーバを選択したかを示して。
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パケットがOFFERパケットに含まれていたオプションを含んでいて、Server Identifierがクライアントによって指定されたものに合っているサーバは反応します、アドレスが割り当てたAddress RangesオプションリストのListと同様に。 パケットをOFFERに送った他のすべてのサーバが、クライアントのためにアドレスを予約するのを止めて、全体の交換を忘れます。
The client now has a two hour "lease" on the multicast address.
クライアントは現在、マルチキャストアドレスに2時間の「リース」を持っています。
If the client had not received an ACK from the server, it would have retransmitted its REQUEST packet for a while. If it still received no response, it would start over with a new DISCOVER message.
クライアントがサーバからACKを受け取らなかったなら、それはしばらく、REQUESTパケットを再送したでしょうに。 まだ応答を全く受けていないなら、新しいDISCOVERメッセージで、やり直すでしょうに。
Hanna, et al. Standards Track [Page 48] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[48ページ]。
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
サーバClient Server(選択されません)(選択される)v対v| | | |マルチキャストアドレス要求を始めてください。| | | | | _____________/|\_____________ | |/は発見します。| \を発見してください。| | | | 蓄え| 蓄えのアドレス| アドレス| | | |\ | ____________/| | \_________ | /申し出| | \を提供してください。|/ | | \ | | | 回答を集めます。| | \| | | サーバを選択します。| | | | | _____________/|\_____________ | |/要求| \を要求してください。| | | | | | アドレスを遂行します。| | | | | _____________/| | |/ACK| | | | | 課題完全です。| | | | v vに対して
Figure 3: Timeline diagram of messages exchanged
in Multicast Address Allocation example
図3: Multicast Address Allocationの例で交換されたメッセージのスケジュールダイヤグラム
3. Lease Extension
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時間使用のためのグローバルな範囲からマルチキャストアドレスを既に割り当てています。 それがもう1時間リースを広げたがっている以上、それが決めるこの2時間までのハーフウェイ。
The client unicasts a RENEW packet to the server from which it allocated the address. This packet includes the Lease Time and Lease Identifier options. The Lease Identifier matches the one used for the original allocation. The time included in the Lease Time is two
それがアドレスを割り当てたサーバへのクライアントユニキャストa RENEWパケット。 このパケットはLease TimeとLease Identifierオプションを含んでいます。 Lease Identifierはオリジナルの配分に使用されるものに合っています。 Lease Timeに時間を含むのは、2です。
Hanna, et al. Standards Track [Page 49] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[49ページ]。
hours, since the client wants the lease to expire two hours from the current time.
クライアントが、リースが現在の時間から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パケットが、リース拡大が承諾されたのを示していて、サーバは反応します。 このパケットはAddress RangesオプションのLease Time、Server Identifier、Lease Identifier、Multicast Scope、およびListを含んでいます。
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.
サーバが要求されたリース拡大を承諾したくなかったなら、それはLease IdentifierオプションがあるNAKパケットで応じたでしょう。
The following figure illustrates this exchange.
以下の図はこの交換を例証します。
Client Server
v v
| |
|\_____________ |
| RENEW \|
| |
| Extends lease
| |
| _____________/|
|/ ACK |
| |
| |
v v
クライアントServer対v| | |\_____________ | | \を更新してください。| | | | リースを広げています。| | | _____________/| |/ACK| | | | | vに対して
Figure 4: Timeline diagram of messages exchanged
in Lease Extension example
図4: Lease Extensionの例で交換されたメッセージのスケジュールダイヤグラム
4. Address Release
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.
それがアドレスを割り当てたサーバへのクライアントユニキャストa RELEASEパケット。 このパケットはLease Identifierオプションを含んでいます。 Lease Identifierはオリジナルの配分に使用されるものに合っています。 サーバがこのパケットを受けるとき、それは、アドレスでクライアントのリースを中止して、リースがリリースされたのを示すクライアントにACKパケットを送ります。 このパケットはServer IdentifierとLease Identifierオプションを含んでいます。
Hanna, et al. Standards Track [Page 50] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[50ページ]。
The following figure illustrates this exchange.
以下の図はこの交換を例証します。
Client Server
v v
| |
|\_____________ |
| RELEASE \|
| |
| Cancels lease
| |
| _____________/|
|/ ACK |
| |
v v
クライアントServer対v| | |\_____________ | | リリース\| | | | リースを中止します。| | | _____________/| |/ACK| | | vに対して
Figure 5: Timeline diagram of messages exchanged
in Address Release example
図5: Address Releaseの例で交換されたメッセージのスケジュールダイヤグラム
5. Unicast Address Allocation
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.
これは前の例の継続です。 何らかの後の時間に、クライアントは、別のマルチキャストアドレスを割り当てると決めます。 最近サーバで働いていたので、それは、ユニキャストREQUESTをそのサーバに送ってみると決めます。これが働いていないなら、いつもDISCOVERの、そして、例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.
それがアドレスを割り当てたがっているサーバへのクライアントユニキャストa REQUESTパケット。 このパケットはLease Time、Lease Identifier、およびMulticast Scopeオプションを含んでいます。
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パケットがLease Time、Lease Identifier、およびMulticast Scopeオプションを含んでいて、サーバはREQUESTパケットから反応します、アドレスが割り当てたAddress RangesオプションリストのServer IdentifierオプションとListと同様に。
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を受け取らなかったなら、それはしばらく、REQUESTパケットを再送したでしょうに。 まだ応答を全く受けていないなら、マルチキャストDISCOVERメッセージで、やり直すでしょうに。
Hanna, et al. Standards Track [Page 51] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[51ページ]。
The following figure illustrates this exchange.
以下の図はこの交換を例証します。
Client Server
v v
| |
|\_____________ |
| REQUEST \|
| |
| Allocates address
| |
| _____________/|
|/ ACK |
| |
v v
クライアントServer対v| | |\_____________ | | \を要求してください。| | | | アドレスを割り当てます。| | | _____________/| |/ACK| | | vに対して
Figure 6: Timeline diagram of messages exchanged
in Unicast Address Allocation example
図6: Unicast Address Allocationの例で交換されたメッセージのスケジュールダイヤグラム
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)
一定の名前推奨値------------- ----------------- 数分[DISCOVER-DELAY]電流が再送する[CLOCK-SKEW-ALLOWANCE]30は1時間60秒[OFFER-HOLD]少なくとも60秒[RESPONSE-CACHE-INTERVAL][XID-REUSE-INTERVAL]10が書き留める[RESPONSE-DELAYがありません]少なくとも60秒(5分の最大)を遅らせます[EXTRA-ALLOCATION-タイム誌]。(必要)です。
Table 6: Recommended Constant Values
テーブル6: お勧めの恒常価値
Hanna, et al. Standards Track [Page 52] RFC 2730 MADCAP December 1999
ハンナ、他 規格は1999年12月にRFC2730無鉄砲者を追跡します[52ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Hanna, et al. Standards Track [Page 53]
ハンナ、他 標準化過程[53ページ]
一覧
スポンサーリンク
