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
Network Working Group S. Hanna
Requests for Comments: 2730 Sun Microsystems, Inc.
Category: Standards Track B. Patel
Intel Corp.
M. Shah
Microsoft Corp.
December 1999
Multicast Address Dynamic Client Allocation Protocol (MADCAP)
多播地址动态客户端分配协议（MADCAP）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document defines a protocol, Multicast Address Dynamic Client Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers.
本文档定义了一个协议，多播地址动态客户端分配协议（MADCAP），该协议允许主机从多播地址分配服务器请求多播地址。
Multicast Address Dynamic Client Allocation Protocol (MADCAP) is a protocol that allows hosts to request multicast address allocation services from multicast address allocation servers. This protocol is part of the Multicast Address Allocation Architecture being defined by the IETF Multicast Address Allocation Working Group. However, it may be used separately from the rest of that architecture as appropriate.
多播地址动态客户端分配协议（MADCAP）是一种允许主机从多播地址分配服务器请求多播地址分配服务的协议。该协议是IETF多播地址分配工作组定义的多播地址分配体系结构的一部分。但是，它可以根据需要与该体系结构的其余部分分开使用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [9].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[9]中所述进行解释。
Constants used by this protocol are shown as [NAME-OF-CONSTANT], and summarized in Appendix B.
本协议使用的常数显示为[常数名称]，并在附录B中汇总。
This specification uses a number of terms that may not be familiar to the reader. This section defines some of these and refers to other documents for definitions of others.
本规范使用了一些读者可能不熟悉的术语。本节对其中一些进行了定义，并参考了其他文件对其他文件进行了定义。
MADCAP client or client A host requesting multicast address allocation services via MADCAP.
MADCAP客户端或客户端通过MADCAP请求多播地址分配服务的主机。
MADCAP server or server A host providing multicast address allocation services via MADCAP.
MADCAP服务器通过MADCAP提供多播地址分配服务的主机。
Multicast IP Multicast, as defined in [11] and modified in [12].
多播IP多播，如[11]中定义并在[12]中修改。
Multicast Address An IP multicast address or group address, as defined in [11] and [13]. An identifier for a group of nodes.
多播地址[11]和[13]中定义的IP多播地址或组地址。一组节点的标识符。
Multicast Scope A range of multicast addresses configured so that traffic sent to these addresses is limited to some subset of the internetwork. See [3] and [13].
多播作用域配置的多播地址范围，以便发送到这些地址的通信量仅限于互联网的某个子集。见[3]和[13]。
Scope ID The lowest numbered address in a multicast scope. This definition applies only within this document.
作用域ID多播作用域中编号最低的地址。本定义仅适用于本文件。
Scope Zone One multicast scope may have several instances, which are known as Scope Zones or zones, for short.
作用域区域一个多播作用域可能有多个实例，简称为作用域区域。
For instance, an organization may have multiple sites. Each site might have its own site-local Scope Zone, each of which would be an instance of the site-local Scope. However, a given interface on a given host would only ever be in at most one instance of a given scope. Messages sent by a host in a site-local Scope Zones to an address in the site-local Scope would be limited to the site-local Scope Zone containing the host.
例如，一个组织可能有多个站点。每个站点可能都有自己的站点本地范围区域，每个区域都是站点本地范围的实例。但是，给定主机上的给定接口最多只能在给定范围的一个实例中。站点本地作用域区域中的主机发送到站点本地作用域中地址的消息将限于包含主机的站点本地作用域区域。
Zone Name A human readable name for a Scope Zone. An ISO 10646 character string with an RFC 1766 [6] language tag. One zone may have several zone names, each in a different language. For instance, a zone for use within IBM's locations in Switzerland might have the names "IBM Suisse", "IBM Switzerland", "IBM Schweiz", and "IBM Svizzera" with language tags "fr", "en", "de", and "it".
区域名称范围区域的可读名称。带有RFC1766[6]语言标记的ISO10646字符串。一个区域可能有多个区域名称，每个名称使用不同的语言。例如，IBM在瑞士的位置内使用的区域可能有名称“IBM Suisse”、“IBM Switzer”、“IBM Schweiz”和“IBM Svizzera”，并带有语言标记“fr”、“en”、“de”和“it”。
Multicast Scope List A list of multicast scope zones.
多播作用域列表多播作用域区域的列表。
Since it can be difficult to determine which multicast scope zones are in effect, MADCAP clients can ask MADCAP servers to supply a Multicast Scope List listing all of the zones available to the client. For each scope zone, the list includes the range of multicast addresses for this scope, a maximum TTL or hop count to be used for this scope, and one or more zone names for this scope zone.
由于很难确定哪些多播作用域有效，MADCAP客户端可以要求MADCAP服务器提供一个多播作用域列表，列出客户端可用的所有区域。对于每个作用域区域，该列表包括此作用域的多播地址范围、用于此作用域的最大TTL或跃点计数，以及此作用域区域的一个或多个区域名称。
This definition applies only within this document.
本定义仅适用于本文件。
For multicast applications to be deployed everywhere, there is a need to define a protocol that any host may use to allocate multicast addresses. Here are the requirements for such a protocol.
为了在任何地方部署多播应用程序，需要定义一个协议，任何主机都可以使用该协议来分配多播地址。以下是对此类协议的要求。
Quick response: The host should be able to allocate a multicast address and begin to use it promptly.
快速响应：主机应该能够分配一个多播地址并立即开始使用它。
Low network load: Hosts that are not allocating or deallocating multicast addresses at the present time should not need to send or receive any network traffic.
低网络负载：当前未分配或取消分配多播地址的主机不需要发送或接收任何网络流量。
Support for intermittently connected or power managed systems: Hosts should be able to be disconnected from the network, powered off, or otherwise inaccessible except during the brief period during which they are allocating a multicast address.
支持间歇性连接或电源管理系统：主机应能够从网络断开连接、关闭电源或以其他方式无法访问，除非在分配多播地址的短暂时间内。
Multicast address scopes: The protocol must be able to allocate both the administratively scoped and globally scoped multicast addresses.
多播地址范围：协议必须能够分配管理范围和全局范围的多播地址。
Efficient use of address space: The multicast address space is fairly small. The protocol should make efficient use of this scarce resource.
有效利用地址空间：多播地址空间相当小。该议定书应有效利用这一稀缺资源。
Authentication: Because multicast addresses are scarce, it is important to protect against hoarding of these addresses. One way to do this is by authenticating clients. This is also a key prerequisite for establishing policies.
身份验证：因为多播地址很少，所以保护这些地址不被囤积是很重要的。一种方法是通过对客户端进行身份验证。这也是制定政策的关键先决条件。
Policy neutral: Allocation policies (such as who can allocate addresses) should not be dictated by the protocol.
策略中立：分配策略（例如谁可以分配地址）不应由协议决定。
Conferencing support: When allocating an address for use in a conferencing environment, members of the conference should be able to modify a multicast address lease used for the conference.
会议支持：分配用于会议环境的地址时，会议成员应该能够修改用于会议的多播地址租约。
MADCAP was originally based on DHCP. There are still some similarities and it may be possible to share some code between a DHCP implementation and a MADCAP implementation. However, MADCAP is completely separate from DHCP, with no dependencies between the two and many significant differences.
MADCAP最初基于DHCP。还有一些相似之处，在DHCP实现和MADCAP实现之间可以共享一些代码。但是，MADCAP与DHCP完全独立，两者之间没有依赖关系，并且存在许多显著差异。
MADCAP is built on a client-server model, where hosts request address allocation services from address allocation servers. When a MADCAP client wishes to request a service, it unicasts or multicasts a message to one or more MADCAP servers, each of which optionally responds with a message unicast to the client.
MADCAP建立在客户机-服务器模型上，主机从地址分配服务器请求地址分配服务。当MADCAP客户端希望请求服务时，它会单播或多播一条消息到一个或多个MADCAP服务器，每个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数据包含固定长度标头和可变长度选项字段。选项以类型长度值格式编码，带有两个八位字节类型和值字段。固定字段有version、msgtype（消息类型）、addrfamily（地址族）和xid（事务标识符）。
Retransmission is handled by the client. If a client sends a message and does not receive a response, it may retransmit its request a few times using an exponential backoff. To avoid executing the same client request twice when a retransmitted request is received, servers cache responses for a short period of time and resend cached responses upon receiving retransmitted requests.
重新传输由客户端处理。如果客户机发送消息但未收到响应，它可能会使用指数退避多次重新传输其请求。为了避免在接收到重新传输的请求时两次执行相同的客户端请求，服务器会在短时间内缓存响应，并在接收到重新传输的请求时重新发送缓存的响应。
Each request contains a msgtype, an xid, and a Lease Identifier option. Clients must ensure that this triple is probably unique across all MADCAP messages received by a MADCAP server over a period of [XID-REUSE-INTERVAL] (10 minutes). This allows the MADCAP server to use this triple as the key in its response cache.
每个请求都包含一个msgtype、一个xid和一个租约标识符选项。客户端必须确保在[XID-REUSE-INTERVAL]（10分钟）期间，MADCAP服务器接收到的所有MADCAP消息中，此三元组可能是唯一的。这允许MADCAP服务器将此三元组用作其响应缓存中的密钥。
Messages sent by servers include the xid included in the original request so that clients can match up responses with requests.
服务器发送的消息包括原始请求中包含的xid，以便客户端可以将响应与请求相匹配。
The msgtype field is a single octet that defines the "type" of a MADCAP message. Currently defined message types are listed in Table 2. They are: DISCOVER, OFFER, REQUEST, RENEW, ACK, NAK, RELEASE, and
msgtype字段是一个八位字节，用于定义MADCAP消息的“类型”。表2中列出了当前定义的消息类型。它们是：发现、提供、请求、续订、确认、NAK、发布和
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.
获取信息。发现、请求、续订、发布和获取信息消息仅由客户端发送。提供、确认和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.
请求、续订和释放消息用于请求、续订或释放一个或多个多播地址的租约。客户端将这些消息中的一条单播到服务器，服务器用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服务器。客户端可以单播GETINFO消息到MADCAP服务器。但是，它可能不知道任何MADCAP服务器的IP地址。在这种情况下，它会将GETINFO消息多播到MADCAP服务器多播地址，所有希望响应的服务器都会将单播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服务器多播地址。IANA已将此地址保留为与多播作用域的最后一个地址相对偏移量为-1的地址。MADCAP客户端使用此地址查找MADCAP服务器。
The DISCOVER message is a message used to discover MADCAP servers that can probably satisfy a REQUEST. DISCOVER messages are always multicast. Servers that can probably satisfy a REQUEST corresponding to the parameters supplied in the DISCOVER message temporarily reserve the addresses needed and send a unicast OFFER back to the client. The client selects a server with which to continue and sends a multicast REQUEST including the server's Server Identifier to the same multicast address used for the DISCOVER. The chosen server responds with an ACK or NAK and the other servers stop reserving the addresses they were temporarily holding.
DISCOVER消息用于发现可能满足请求的MADCAP服务器。发现消息总是多播的。可能满足与DISCOVER消息中提供的参数对应的请求的服务器临时保留所需的地址，并将单播提供发送回客户端。客户端选择要继续的服务器，并将包含服务器标识符的多播请求发送到用于发现的同一多播地址。所选服务器用ACK或NAK响应，其他服务器停止保留它们临时保留的地址。
For detailed descriptions of typical protocol exchanges, consult Appendix A.
有关典型协议交换的详细说明，请参阅附录A。
MADCAP is a mechanism rather than a policy. MADCAP allows local system administrators to exercise control over configuration parameters where desired. For example, MADCAP servers may be configured to limit the number of multicast addresses allocated to a single client. Properly enforcing such a limit requires cryptographic security, as described in the Security Consideration section.
MADCAP是一种机制，而不是一种政策。MADCAP允许本地系统管理员在需要时对配置参数进行控制。例如，MADCAP服务器可以配置为限制分配给单个客户端的多播地址的数量。如安全考虑部分所述，正确实施此类限制需要加密安全性。
MADCAP requests from a single host may be sent on behalf of different applications with different needs and requirements. MADCAP servers MUST NOT assume that because one request from a MADCAP client supports a particular optional feature (like Retry After), future requests from that client will also support that optional feature.
来自单个主机的MADCAP请求可以代表具有不同需求和要求的不同应用程序发送。MADCAP服务器不能假设，因为来自MADCAP客户端的一个请求支持特定的可选功能（如重试后），所以来自该客户端的未来请求也将支持该可选功能。
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 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的保留端口号（端口号2535，由IANA分配）。客户端计算机上可以使用任何端口号。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消息格式和消息类型。第3节提供了MADCAP选项的完整列表。
Figure 1 gives the format of a MADCAP message and Table 1 describes each of the fields in the MADCAP message. The numbers in parentheses indicate the size of each field in octets. The names for the fields given in the figure will be used throughout this document to refer to the fields in MADCAP messages.
图1给出了MADCAP消息的格式，表1描述了MADCAP消息中的每个字段。括号中的数字以八位字节表示每个字段的大小。图中给出的字段名称将在本文档中用于引用MADCAP消息中的字段。
All multi-octet quantities are in network byte-order.
所有多个八位字节数量均按网络字节顺序排列。
Any message whose UDP data is too short to hold this format (at least 12 bytes) MUST be ignored.
必须忽略UDP数据太短而无法保存此格式（至少12字节）的任何消息。
+-+-+-+-+-+-+-+-+
| version (1) |
+---------------+
| msgtype (1) |
+---------------+
| addrfamily |
| (2) |
+---------------+
| |
| xid (4) |
| |
| |
+---------------+
| |
| options |
| (variable) |
| ... |
+---------------+
+-+-+-+-+-+-+-+-+
| version (1) |
+---------------+
| msgtype (1) |
+---------------+
| addrfamily |
| (2) |
+---------------+
| |
| xid (4) |
| |
| |
+---------------+
| |
| options |
| (variable) |
| ... |
+---------------+
Figure 1: Format of a MADCAP message
图1:MADCAP消息的格式
FIELD OCTETS DESCRIPTION
----- ------ -----------
FIELD OCTETS DESCRIPTION
----- ------ -----------
version 1 Protocol version number (zero for this specification) msgtype 1 Message type (DISCOVER, GETINFO, etc.) addrfamily 2 Address family (IPv4, IPv6, etc.) xid 4 Transaction ID options var Options field
版本1协议版本号（此规范为零）msgtype 1消息类型（发现、获取信息等）addrfamily 2地址系列（IPv4、IPv6等）xid 4事务ID选项变量选项字段
Table 1: Description of fields in a MADCAP message
表1:MADCAP消息中字段的说明
The version field must always be zero for this version of the protocol. Any messages that include other values in this field MUST be ignored.
对于此版本的协议，版本字段必须始终为零。必须忽略此字段中包含其他值的任何消息。
The msgtype field defines the "type" of the MADCAP message.
msgtype字段定义MADCAP消息的“类型”。
For more information about this field, see section 2.2.
有关此字段的更多信息，请参阅第2.2节。
The addrfamily field defines the default address family (such as IPv4 or IPv6) for this MADCAP message, using the address family numbers defined in by the IANA (including those defined in [10]). Unless otherwise specified, all addresses included in the message will be from this family.
addrfamily字段使用IANA在中定义的地址系列号（包括[10]中定义的地址系列号）定义此MADCAP消息的默认地址系列（如IPv4或IPv6）。除非另有规定，邮件中包含的所有地址都将来自此系列。
The xid field is a transaction identifier. This number MUST be chosen by the client so that the combination of xid, msgtype, and Lease Identifier is unique across all MADCAP messages received by a MADCAP server over a period of [XID-REUSE-INTERVAL] (10 minutes).
xid字段是事务标识符。客户端必须选择此号码，以便在[xid-REUSE-INTERVAL]（10分钟）期间，MADCAP服务器接收到的所有MADCAP消息中，xid、msgtype和租约标识符的组合都是唯一的。
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-REUSE-INTERVAL]内的两条不同消息不可能使用相同的xid、msgtype和租约标识符组合（即使在多个互不通信的客户端之间）。这允许有足够的时间从所有服务器响应缓存中删除消息（如下面几段所述），并允许任何网络延迟。
The RECOMMENDED technique for choosing an xid is to choose a random four octet number as the first xid in a session and increment this value each time a new xid is needed. The random number chosen need not be cryptographically random. The random number may be chosen via any suitable technique, such as the one described in section A.6 of RFC 1889 [14].
选择xid的推荐技术是选择一个随机的四个八位组数作为会话中的第一个xid，并在每次需要新的xid时增加该值。选择的随机数不需要是加密随机数。可通过任何合适的技术选择随机数，如RFC 1889[14]第A.6节所述的技术。
When a server responds to a client message, it MUST use the same xid value in the response that the client used in the request. This allows the client to associate responses with the message that they are responding to.
当服务器响应客户机消息时，它必须在响应中使用与客户机在请求中使用的相同的xid值。这允许客户端将响应与其响应的消息相关联。
When retransmitting messages (as described in section 2.3), the client MUST retransmit them without changing them, thereby using the same xid and and Lease Identifier.
当重新传输消息时（如第2.3节所述），客户端必须在不更改消息的情况下重新传输消息，从而使用相同的xid和租约标识符。
If a server receives a message with the same xid, msgtype, and Lease Identifier as one received within [RESPONSE-CACHE-INTERVAL], it MUST treat this message as a retransmission of the previously received one and retransmit the response, if any. After [RESPONSE-CACHE-INTERVAL], the server may forget about the previously received message and treat
如果服务器接收到与[RESPONSE-CACHE-INTERVAL]内接收到的消息具有相同xid、msgtype和租约标识符的消息，则必须将此消息视为先前接收到的消息的重新传输，并重新传输响应（如果有）。在[RESPONSE-CACHE-INTERVAL]之后，服务器可能会忘记以前接收到的消息并处理
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秒，但它可能有0秒到300秒（5分钟）之间的任何值，并且可以根据服务器上的资源限制进行动态调整。但是，不建议使用小于60秒的值，因为这是正常的客户端重新传输周期。
The options field consists of a list of tagged parameters that are called "options". All options consist of a two octet option code and a two octet option length, followed by the number of octets specified by the option length. In the case of some options, the length field is a constant but must still be specified.
“选项”字段包含一个标记参数列表，这些参数称为“选项”。所有选项都由两个八位字节选项代码和两个八位字节选项长度组成，后跟选项长度指定的八位字节数。对于某些选项，长度字段是一个常量，但仍必须指定。
The option field MUST contain a sequence of options with the last one being the End option (option code 0). Any message whose options field does not conform to this syntax MUST be ignored.
选项字段必须包含一系列选项，最后一个选项是结束选项（选项代码0）。必须忽略其选项字段不符合此语法的任何消息。
Any MADCAP client or server sending a MADCAP message MAY include any of the options listed in section 3, subject to the restrictions in Table 5 and elsewhere in this document. They MAY also include other MADCAP options that are defined in the future. A MADCAP client or server MUST NOT include more than one option with the same option type in one MADCAP message.
发送MADCAP消息的任何MADCAP客户端或服务器可包括第3节中列出的任何选项，但须遵守表5和本文件其他地方的限制。它们还可能包括将来定义的其他MADCAP选项。MADCAP客户端或服务器不得在一条MADCAP消息中包含多个具有相同选项类型的选项。
All MADCAP clients and servers MUST recognize all options listed in this document and behave in accordance with this document when receiving and processing any of these options. Any unrecognized options MUST be ignored and the rest of the message processed as if the unknown options were not present. If a MADCAP server receives a message that does not conform to the requirements of this document (for instance, not including all required options), an Invalid Request error MUST be generated and processed in the manner described in section 2.6. If a MADCAP client receives a message that does not conform to the requirements of this document, it MUST ignore the message.
所有MADCAP客户端和服务器必须识别本文档中列出的所有选项，并在接收和处理这些选项时按照本文档行事。必须忽略任何无法识别的选项，并处理消息的其余部分，就像未知选项不存在一样。如果MADCAP服务器收到不符合本文件要求的消息（例如，不包括所有必需选项），则必须以第2.6节所述的方式生成并处理无效请求错误。如果MADCAP客户端收到不符合本文档要求的消息，则必须忽略该消息。
The order of options within a message has no significance and any order MUST be supported in an equivalent manner, with the exception that the End option must occur once per message, as the last option in the option field.
消息中选项的顺序没有意义，必须以等效的方式支持任何顺序，但每个消息必须出现一次结束选项，作为选项字段中的最后一个选项。
New MADCAP option codes may only be defined by IETF Consensus, as described in section 5.
如第5节所述，新的MADCAP选项代码只能由IETF共识定义。
The msgtype field defines the "type" of a MADCAP message. Legal values for this field are:
msgtype字段定义MADCAP消息的“类型”。此字段的法定值为：
Value Message Type
----- ------------
1 DISCOVER
2 OFFER
3 REQUEST
4 RENEW
5 ACK
6 NAK
7 RELEASE
8 GETINFO
Value Message Type
----- ------------
1 DISCOVER
2 OFFER
3 REQUEST
4 RENEW
5 ACK
6 NAK
7 RELEASE
8 GETINFO
Table 2: MADCAP message types
表2:MADCAP消息类型
Throughout this document, MADCAP messages will be referred to by the type of the message; e.g., a MADCAP message with a message type of 8 will be referred to as an GETINFO message.
在本文件中，MADCAP消息将按消息类型引用；e、 例如，消息类型为8的MADCAP消息将被称为GETINFO消息。
Here are descriptions of the MADCAP message types. Table 5, which appears at the beginning of section 3, summarizes which options are allowed with each message type.
下面是MADCAP消息类型的描述。第3节开头的表5总结了每种消息类型允许的选项。
MADCAP clients and servers MUST handle all MADCAP message types defined in this document in a manner consistent with this document.
MADCAP客户端和服务器必须以与本文档一致的方式处理本文档中定义的所有MADCAP消息类型。
If a MADCAP server receives a message whose message type it does not recognize, an Invalid Request error MUST be generated and processed in the manner described in section 2.6. If a MADCAP client receives a message whose message type it does not recognize, it MUST ignore the message.
如果MADCAP服务器接收到无法识别其消息类型的消息，则必须以第2.6节所述的方式生成并处理无效请求错误。如果MADCAP客户端接收到其消息类型无法识别的消息，则必须忽略该消息。
Note, however, that under some circumstances this document requires or suggests that clients or servers ignore messages with certain message types even though they may be recognized. For instance, clients that do not send DISCOVER messages SHOULD ignore OFFER messages. Also, secure servers SHOULD ignore DISCOVER messages and all servers SHOULD ignore DISCOVER messages that they cannot satisfy.
但是，请注意，在某些情况下，本文档要求或建议客户机或服务器忽略某些消息类型的消息，即使它们可能被识别。例如，不发送发现消息的客户端应该忽略提供消息。此外，安全服务器应该忽略发现消息，所有服务器都应该忽略它们无法满足的发现消息。
New MADCAP message types may only be defined by IETF Consensus, as described in section 5.
新的MADCAP消息类型只能由IETF共识定义，如第5节所述。
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.
要获取配置参数，特别是多播作用域列表的MADCAP客户端使用GETINFO消息。此消息还允许客户端确定哪些服务器可能能够处理未来的请求。
The MADCAP client sends out an GETINFO message. The message may be unicast to a particular MADCAP server or multicast to a MADCAP Server Multicast Address. For more details about the MADCAP Server Multicast Address, see section 2.10.
MADCAP客户端发送一条GETINFO消息。消息可以单播到特定的MADCAP服务器，或者多播到MADCAP服务器多播地址。有关MADCAP服务器多播地址的更多详细信息，请参阅第2.10节。
If a server receives an GETINFO message and it can process the request successfully, it MUST unicast an ACK message to the client. All GETINFO messages MUST include an Option Request List option. The server SHOULD try to include the specified options in its response, but is not required to do so (especially if it does not recognize them).
如果服务器接收到GETINFO消息并且能够成功处理请求，则必须单播ACK消息到客户端。所有GETINFO消息必须包含选项请求列表选项。服务器应该尝试在其响应中包含指定的选项，但不需要这样做（特别是在它无法识别这些选项的情况下）。
If a server receives an GETINFO message and it does not process the request successfully, it MUST generate and process an error in the manner described in section 2.6.
如果服务器收到GETINFO消息，但未成功处理请求，则必须按照第2.6节所述的方式生成并处理错误。
If a client sends an GETINFO message and does not receive any ACK messages in response, it SHOULD resend its GETINFO message, as described in section 2.3.
如果客户端发送GETINFO消息，但没有收到任何ACK消息作为响应，则应重新发送其GETINFO消息，如第2.3节所述。
When a MADCAP client sends an GETINFO message, it MAY include the Requested Language option, which specifies which language the client would prefer for the zone names in the Multicast Scope List. The proper way to handle this tag with respect to zone names is discussed in the definition of the Multicast Scope List option.
当MADCAP客户端发送GETINFO消息时，它可能包括请求的语言选项，该选项指定客户端在多播作用域列表中对区域名称首选的语言。在多播作用域列表选项的定义中讨论了处理与区域名称相关的标记的正确方法。
The DISCOVER message is a multicast message sent by a MADCAP client that wants to discover MADCAP servers that can probably satisfy a REQUEST.
发现消息是由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客户端不需要使用发现消息。他们可能会使用其他方法来查找MADCAP服务器，例如发送多播GETINFO消息、缓存过去工作的IP地址或配置IP地址。使用DISCOVER消息有一个特殊的优点，即它允许客户端从所有能够满足请求的服务器接收响应。
The MADCAP client begins by sending a multicast DISCOVER message to a MADCAP Server Multicast Address. Any servers that wish to assist the client respond by sending a unicast OFFER message to the client. If a server can only process the request with a shorter lease time or later start time than the client requested, it SHOULD send an OFFER message with the lease time or start time that it can offer. However, it MUST NOT offer a lease time shorter than the minimum lease time specified by the client or a start time later than the maximum start time specified by the client.
MADCAP客户端首先向MADCAP服务器多播地址发送多播发现消息。任何希望帮助客户机的服务器都会通过向客户机发送单播提供消息进行响应。如果服务器只能处理租赁时间比客户机请求的租赁时间短或启动时间晚的请求，则应发送一条包含其可以提供的租赁时间或启动时间的要约消息。但是，其租赁时间不得短于客户指定的最小租赁时间或晚于客户指定的最大开始时间。
For more details about the MADCAP Server Multicast Address, see section 2.10.
有关MADCAP服务器多播地址的更多详细信息，请参阅第2.10节。
If a client sends a DISCOVER message and does not receive any OFFER messages in response, the client SHOULD retransmit its DISCOVER message, as described in section 2.3.
如果客户机发送发现消息，但未收到任何报价消息作为响应，则客户机应重新传输其发现消息，如第2.3节所述。
If a client sends a DISCOVER message and receives one or more OFFER messages in response, it SHOULD select the server it wants to use (if any) and send a multicast REQUEST message identifying that server within [DISCOVER-DELAY] after receiving the first OFFER message. See section 2.2.4 for more information about the REQUEST message.
如果客户机发送发现消息并收到一条或多条要约消息作为响应，则应选择其想要使用的服务器（如果有），并在收到第一条要约消息后的[DISCOVER-DELAY]内发送标识该服务器的多播请求消息。有关请求消息的更多信息，请参见第2.2.4节。
The mechanism used by the client in selecting the server it wants to use is implementation dependent. The client MAY choose the first acceptable response or it MAY wait some period of time (no more than [DISCOVER-DELAY]) and choose the best response received in that period of time (if the first response has a smaller lease time than requested, for instance).
客户端在选择要使用的服务器时使用的机制取决于实现。客户机可以选择第一个可接受的响应，也可以等待一段时间（不超过[DISCOVER-DELAY]），然后选择在该时间段内收到的最佳响应（例如，如果第一个响应的租用时间小于请求的时间）。
The value of [DISCOVER-DELAY] is also implementation dependent, but the RECOMMENDED value is the current retransmit timer, as specified in section 2.3. Waiting too long (approaching [OFFER-HOLD]) may cause servers to drop the addresses they have reserved.
[DISCOVER-DELAY]的值也取决于实现，但建议的值是第2.3节中规定的当前重传计时器。等待太长时间（接近[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客户端发送发现消息时，它可能包括租约时间、最短租约时间、开始时间、最长开始时间、请求的地址数和地址范围选项列表，描述它想要接收的地址。但是，它不需要包括这些选项中的任何一个。如果未包括其中一个选项，服务器将提供相应的默认值（可用于租赁时间的最大值，不可用于最小租赁时间的最小值，尽快用于开始时间，不可用于最大开始时间的最大值，一个用于请求的地址数，以及可用于地址范围列表的任何地址）。多播作用域选项必须包含在发现消息中，以便服务器知道应该使用哪个作用域。如果包含“开始时间”或“最大开始时间”选项，则必须包含“当前时间”选项。租约标识符选项
MUST always be included.
必须始终包括。
The OFFER message is a unicast message sent by a MADCAP server in response to a DISCOVER message that it can probably satisfy.
OFFER消息是由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服务器不需要发送要约消息来响应发现消息。例如，它可能无法满足客户端的请求，或者可能已配置为仅响应某些类型的发现消息，或者根本不响应发现消息。
If a MADCAP server decides to send an OFFER message, it MUST include the Lease Time and Multicast Scope options, describing the addresses it is willing to provide. However, it need not include the List of Address Ranges option. If the List of Address Ranges Allocated option is not included, it is assumed that the server is willing to provide the number of addresses that the client requested. If the Start Time option is not included, it is assumed that the server is willing to provide the start time requested by the client (if any). The Current Time option MUST be included if the Start Time option is included.
如果MADCAP服务器决定发送要约消息，它必须包括租赁时间和多播作用域选项，描述它愿意提供的地址。但是，它不需要包括地址范围列表选项。如果未包括分配的地址范围列表选项，则假定服务器愿意提供客户端请求的地址数。如果未包括启动时间选项，则假定服务器愿意提供客户端请求的启动时间（如果有）。如果包含“开始时间”选项，则必须包含“当前时间”选项。
If a server can process the request with a shorter lease time or later start time than the client requested, it SHOULD send an OFFER message with the lease time or start time that it can offer. However, it MUST NOT offer a lease time shorter than the minimum lease time specified by the client or a start time later than the maximum start time specified by the client.
如果服务器处理请求的租赁时间比客户端请求的租赁时间短或启动时间晚，则应发送一条包含其可以提供的租赁时间或启动时间的要约消息。但是，其租赁时间不得短于客户指定的最小租赁时间或晚于客户指定的最大开始时间。
If the server sends an OFFER message, it SHOULD attempt to hold enough addresses to complete the transaction. If it receives a multicast REQUEST message with the same Lease Identifier option as the DISCOVER message for which it is holding these addresses and a Server Identifier option that does not match its own, it SHOULD stop holding the addresses. The server SHOULD also stop holding the addresses after an appropriate delay [OFFER-HOLD] if the transaction is not completed. The value of this delay is implementation-specific, but a value of at least 60 seconds is RECOMMENDED.
如果服务器发送OFFER消息，它应该尝试保存足够的地址以完成事务。如果它接收到一条多播请求消息，该消息与它持有这些地址的发现消息具有相同的租约标识符选项，并且服务器标识符选项与其自身不匹配，则它应该停止持有这些地址。如果事务未完成，服务器还应在适当延迟[OFFER-HOLD]后停止保留地址。此延迟的值是特定于实现的，但建议至少为60秒。
As with all messages sent by the server, the xid field MUST match the xid field included in the client request to which this message is responding. The Lease Identifier option MUST be included, with the value matching the one included in the client request. The Server Identifier option MUST be included, with the value being the server's IP address. And the packet MUST NOT be retransmitted.
与服务器发送的所有消息一样，xid字段必须与此消息所响应的客户端请求中包含的xid字段相匹配。必须包含租约标识符选项，其值与客户端请求中包含的值匹配。必须包括服务器标识符选项，其值为服务器的IP地址。并且数据包不能被重新传输。
The REQUEST message is used by a MADCAP client that wants to allocate one or more multicast addresses. It is not used for renewing an existing lease. The RENEW message is used for that.
要分配一个或多个多播地址的MADCAP客户端使用请求消息。它不用于续订现有租约。“续订”消息用于此目的。
If a REQUEST message is completing a transaction initiated by a DISCOVER message, the following procedure MUST be followed so that all MADCAP servers know which server was selected. The client MUST multicast a REQUEST message to the same MADCAP Server Multicast Address that the DISCOVER message was sent to. The same Lease Identifier used in the DISCOVER message MUST be used in the REQUEST message. Also, the Server Identifier option MUST be included, using the Server Identifier of the server selected.
如果请求消息正在完成由发现消息启动的事务，则必须遵循以下过程，以便所有MADCAP服务器都知道选择了哪个服务器。客户端必须将请求消息多播到发现消息发送到的MADCAP服务器多播地址。请求消息中必须使用发现消息中使用的相同租约标识符。此外，必须使用所选服务器的服务器标识符包括服务器标识符选项。
If a REQUEST message is not completing a transaction initiated by a DISCOVER message, the REQUEST message MUST be unicast to the MADCAP server that the client wants to use. In this case, the Server Identifier option MAY be included, but need not be.
如果请求消息未完成由发现消息启动的事务，则请求消息必须单播到客户端想要使用的MADCAP服务器。在这种情况下，可以包括服务器标识符选项，但不需要。
If the selected server can process the request successfully, it SHOULD unicast an ACK message to the client. Otherwise, it SHOULD generate and process an error in the manner described in section 2.6. If a server can process the request with a shorter lease time or later start time than the client requested, it SHOULD send an ACK message with the lease time or start time that it can offer. However, it MUST NOT offer a lease time shorter than the minimum lease time specified by the client or a start time later than the maximum start time specified by the client.
如果所选服务器能够成功处理请求，则应向客户端单播ACK消息。否则，应按照第2.6节所述的方式生成并处理错误。如果服务器处理请求的租用时间比客户端请求的租用时间短或启动时间晚，则应发送一条ACK消息，其中包含服务器可以提供的租用时间或启动时间。但是，其租赁时间不得短于客户指定的最小租赁时间或晚于客户指定的最大开始时间。
When a MADCAP client sends a REQUEST message, it MAY include the Lease Time, Minimum Lease Time, Start Time, Maximum Start Time, Number of Addresses Requested, and List of Address Ranges options, describing the addresses it wants to receive. However, it need not include any of these options. If one of these options is not included, the server will provide the appropriate default (maximum available for Lease Time, no minimum for Minimum Lease Time, as soon as possible for Start Time, no maximum for Maximum Start Time, one for Number of Addresses Requested, and any addresses available for List of Address Ranges). The Multicast Scope option MUST be included in the REQUEST message so that the server knows what scope should be used. The Current Time option MUST be included if the Start Time or Maximum Start Time options are included.
当MADCAP客户端发送请求消息时，它可能包括租约时间、最小租约时间、开始时间、最大开始时间、请求的地址数和地址范围选项列表，描述它想要接收的地址。但是，它不需要包括这些选项中的任何一个。如果未包括其中一个选项，服务器将提供相应的默认值（可用于租赁时间的最大值，不可用于最小租赁时间的最小值，尽快用于开始时间，不可用于最大开始时间的最大值，一个用于请求的地址数，以及可用于地址范围列表的任何地址）。多播作用域选项必须包含在请求消息中，以便服务器知道应该使用哪个作用域。如果包含“开始时间”或“最大开始时间”选项，则必须包含“当前时间”选项。
If a client sends a REQUEST message and does not receive any ACK or NAK messages in response, the client SHOULD resend its REQUEST message, as described in section 2.3.
如果客户端发送请求消息，但没有收到任何ACK或NAK消息作为响应，则客户端应重新发送其请求消息，如第2.3节所述。
If the server responds with a NAK or fails to respond within a reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the client MAY try to find another server by sending a DISCOVER message with another xid or sending a REQUEST message with another xid to another server. The RECOMMENDED value for [NO-RESPONSE-DELAY] is 60 seconds.
如果服务器使用NAK响应或未能在合理的（依赖于实现的）延迟[NO-RESPONSE-delay]内响应，则客户机可以通过使用另一个xid发送发现消息或使用另一个xid向另一个服务器发送请求消息来尝试查找另一个服务器。[无响应延迟]的建议值为60秒。
The ACK message is used by a MADCAP server to respond affirmatively to an GETINFO, REQUEST, or RELEASE message. The server unicasts the ACK message to the client from which it received the message to which it is responding.
MADCAP服务器使用ACK消息对GETINFO、请求或释放消息做出肯定的响应。服务器将ACK消息单播到接收到其响应消息的客户端。
The set of options included with an ACK message differs, depending on what sort of message it is responding to.
ACK消息包含的选项集会有所不同，这取决于它响应的消息的类型。
If the ACK message is responding to an GETINFO message, it SHOULD include any options requested by the client using the Option Request List option.
如果ACK消息响应GETINFO消息，它应该包括客户端使用选项请求列表选项请求的任何选项。
If the ACK message is responding to a REQUEST message, it MUST include Lease Time, Multicast Scope, and List of Address Ranges options. It MAY include a Start Time option. If a Start Time option is included, a Current Time option MUST also be included. If no Start Time option is included, the lease is assumed to start immediately.
如果ACK消息响应请求消息，则它必须包括租用时间、多播作用域和地址范围选项列表。它可能包括一个开始时间选项。如果包括开始时间选项，则还必须包括当前时间选项。如果不包括开始时间选项，则假定租赁立即开始。
If the ACK message is responding to a RENEW message, it MUST include Lease Time, Multicast Scope, and List of Address Ranges options. It MAY include a Start Time option. If a Start Time option is included, a Current Time option MUST also be included. If no Start Time option is included, the lease is assumed to start immediately.
如果ACK消息响应续订消息，则它必须包括租约时间、多播作用域和地址范围选项列表。它可能包括一个开始时间选项。如果包括开始时间选项，则还必须包括当前时间选项。如果不包括开始时间选项，则假定租赁立即开始。
If the ACK message is responding to a RELEASE message, it MUST only include Server Identifier and Lease Identifier options.
如果ACK消息响应发布消息，则它必须仅包括服务器标识符和租约标识符选项。
As with all messages sent by the server, the xid field MUST match the xid field included in the client request to which this message is responding. The Lease Identifier option MUST be included, with the value matching the one included in the client request. The Server Identifier option MUST be included, with the value being the server's IP address. And the packet MUST NOT be retransmitted.
与服务器发送的所有消息一样，xid字段必须与此消息所响应的客户端请求中包含的xid字段相匹配。必须包含租约标识符选项，其值与客户端请求中包含的值匹配。必须包括服务器标识符选项，其值为服务器的IP地址。并且数据包不能被重新传输。
The NAK message is used by a MADCAP server to respond negatively to a message. The server unicasts the NAK message to the client from which it received the message to which it is responding.
MADCAP服务器使用NAK消息对消息做出负面响应。服务器将NAK消息单播到从中接收其响应消息的客户端。
As with all messages sent by the server, the xid field MUST match the xid field included in the client request to which this message is responding. The Lease Identifier option MUST be included, with the value matching the one included in the client request. The Server Identifier option MUST be included, with the value being the server's IP address. The Error option MUST be included with an error code indicating what went wrong. And the packet MUST NOT be retransmitted.
与服务器发送的所有消息一样，xid字段必须与此消息所响应的客户端请求中包含的xid字段相匹配。必须包含租约标识符选项，其值与客户端请求中包含的值匹配。必须包括服务器标识符选项，其值为服务器的IP地址。“错误”选项必须包含一个错误代码，指示出错的原因。并且数据包不能被重新传输。
The RENEW message is used by a MADCAP client that wants to renew a multicast address lease, changing the lease time or start time.
要续订多播地址租约、更改租约时间或开始时间的MADCAP客户端使用续订消息。
The client unicasts the RENEW message to a MADCAP server. If the server can process the request successfully, it SHOULD unicast an ACK message to the client. Otherwise, it MUST generate and process an error in the manner described in section 2.6.
客户端将续订消息单播到MADCAP服务器。如果服务器能够成功地处理请求，它应该向客户端单播ACK消息。否则，必须按照第2.6节所述的方式生成并处理错误。
The lease to be renewed is whichever one was allocated with a Lease Identifier option matching the one provided in the RENEW message.
要续订的租约是分配了与续订消息中提供的租约标识符选项匹配的租约标识符选项的租约。
When a MADCAP client sends a RENEW message, it MAY include the Lease Time, Minimum Lease Time, Start Time, and Maximum Start Time options, describing the new lease it wants to receive. However, it need not include any of these options. If one of these options is not included, the server will provide the appropriate default (maximum available for Lease Time, no minimum for Minimum Lease Time, as soon as possible for Start Time, and no maximum for Maximum Start Time). The Current Time option MUST be included if the Start Time or Maximum Start Time options are included.
当MADCAP客户端发送续订消息时，它可能包括租约时间、最小租约时间、开始时间和最大开始时间选项，描述它想要接收的新租约。但是，它不需要包括这些选项中的任何一个。如果其中一个选项未包括在内，服务器将提供相应的默认值（可用于租赁时间的最大值，最小租赁时间没有最小值，尽快开始时间没有最大值，最大开始时间没有最大值）。如果包含“开始时间”或“最大开始时间”选项，则必须包含“当前时间”选项。
If a client sends a RENEW message and does not receive any ACK or NAK messages in response, the client SHOULD resend its RENEW message, as described in section 2.3.
如果客户端发送续订消息，但未收到任何ACK或NAK消息作为响应，则客户端应重新发送其续订消息，如第2.3节所述。
If the server responds with a NAK or fails to respond within a reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the client MAY send a RENEW message with another xid to another server, provided that the Server Mobility feature was used in the original REQUEST message and that this feature is required for the subsequent RENEW message sent to another server. For more information about the Server Mobility feature, see section 2.13.1. The RECOMMENDED value for [NO-RESPONSE-DELAY] is 60 seconds.
如果服务器使用NAK进行响应或未能在合理的（依赖于实现的）延迟[NO-RESPONSE-delay]内响应，则客户端可以使用另一个xid向另一个服务器发送续订消息，前提是原始请求消息中使用了服务器移动性功能，并且发送到其他服务器的后续续订消息需要此功能。有关服务器移动性功能的更多信息，请参阅第2.13.1节。[无响应延迟]的建议值为60秒。
The RELEASE message is used by a MADCAP client that wants to deallocate one or more multicast addresses before their lease expires.
释放消息由MADCAP客户端使用，该客户端希望在租约到期之前解除分配一个或多个多播地址。
The client unicasts the RELEASE message to the MADCAP server from which it allocated the addresses. If the selected server can process the request successfully, it MUST unicast an ACK message to the client. Otherwise, it MUST generate and process an error in the manner described in section 2.6.
客户端将释放消息单播到MADCAP服务器，并从该服务器分配地址。如果所选服务器可以成功处理请求，则必须单播ACK消息到客户端。否则，必须按照第2.6节所述的方式生成并处理错误。
The lease to be released is whichever one was allocated with a Lease Identifier option matching the one provided in the RELEASE message. It is not possible to release only part of the addresses in a single lease.
要释放的租约是分配了与释放消息中提供的租约标识符选项匹配的租约标识符选项的租约。不可能在单个租约中仅释放部分地址。
If a client sends a RELEASE message and does not receive any ACK or NAK messages in response, the client SHOULD resend its RELEASE message, as described in section 2.3.
如果客户端发送释放消息，但未收到任何ACK或NAK消息作为响应，则客户端应重新发送其释放消息，如第2.3节所述。
If the server responds with a NAK or fails to respond within a reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the client MAY send a RELEASE message with another xid to another server, provided that the Server Mobility feature was used in the original REQUEST message and that this feature is required for the subsequent RELEASE message sent to another server. For more information about the Server Mobility feature, see section 2.13.1. The RECOMMENDED value for [NO-RESPONSE-DELAY] is 60 seconds.
如果服务器使用NAK响应或未能在合理的（依赖于实现的）延迟[NO-RESPONSE-delay]内响应，则客户端可能会使用另一个xid向另一个服务器发送释放消息，前提是原始请求消息中使用了服务器移动性功能，并且发送到其他服务器的后续发布消息需要此功能。有关服务器移动性功能的更多信息，请参阅第2.13.1节。[无响应延迟]的建议值为60秒。
MADCAP clients are responsible for all message retransmission. The client MUST adopt a retransmission strategy that incorporates an exponential backoff algorithm to determine the delay between retransmissions. The delay between retransmissions SHOULD be chosen to allow sufficient time for replies from the server to be delivered based on the characteristics of the internetwork between the client and the server.
MADCAP客户端负责所有消息的重新传输。客户端必须采用包含指数退避算法的重传策略来确定重传之间的延迟。应选择重传之间的延迟，以便根据客户机和服务器之间的互联网络特征，有足够的时间从服务器发送回复。
The RECOMMENDED algorithm is to use a 4 second delay before the first retransmission and to double this delay for each successive retransmission, with a maximum delay of 16 seconds and a maximum of three retransmissions. If an initial transmission was sent at time (in seconds) t and no responses were received, subsequent transmissions would be at t+4, t+12, and t+28. If no response has been received by t+60, the client would stop retransmitting and take another course of action (such as logging an error or sending a
建议的算法是在第一次重传之前使用4秒的延迟，并在每次连续重传时将此延迟加倍，最大延迟为16秒，最多重传三次。如果在时间（以秒为单位）t发送初始传输，并且没有收到响应，则后续传输将在t+4、t+12和t+28处。如果t+60没有收到响应，客户端将停止重新传输，并采取另一种措施（例如记录错误或发送错误消息）
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.
客户端可以向用户提供重传尝试的指示，作为过程进度的指示。客户端可以在任何点停止重新传输。
The Lease Identifier option is included in each MADCAP message. Its value is used to identify a lease and MUST be unique across all leases requested by all clients in a multicast address allocation domain.
租约标识符选项包含在每个MADCAP消息中。它的值用于标识租约，并且在多播地址分配域中的所有客户端请求的所有租约中必须是唯一的。
The first octet of the Lease Identifier is the Lease Identifier type. Table 3 lists the Lease Identifier types defined at this time and sections 2.4.1 and 2.4.2 describe these Lease Identifier types.
租约标识符的第一个八位字节是租约标识符类型。表3列出了此时定义的租赁标识符类型，第2.4.1节和第2.4.2节描述了这些租赁标识符类型。
New MADCAP Lease Identifier types may only be defined by IETF Consensus, as described in section 5.
如第5节所述，新的MADCAP租赁标识符类型只能由IETF共识定义。
Lease Identifier Type Name
--------------------- ----
0 Random Lease Identifier
1 Address-Specific Lease Identifier
Lease Identifier Type Name
--------------------- ----
0 Random Lease Identifier
1 Address-Specific Lease Identifier
Table 3: MADCAP Lease Identifier Types
表3:MADCAP租赁标识符类型
The MADCAP server does not need to parse the Lease Identifier. It SHOULD use the Lease Identifier only as an opaque identifier, which must be unique for each lease. The purpose of defining different Lease Identifier types is to allow MADCAP clients that already have a globally unique address to avoid the possibility of Lease Identifier collisions by using this address together with a client-specific identifier. MADCAP clients that do not have a globally unique address SHOULD use Lease Identifier type 0.
MADCAP服务器不需要解析租约标识符。它应仅将租约标识符用作不透明标识符，该标识符对于每个租约都必须是唯一的。定义不同的租约标识符类型的目的是允许已经具有全局唯一地址的MADCAP客户端通过将此地址与特定于客户端的标识符一起使用来避免租约标识符冲突的可能性。没有全局唯一地址的MADCAP客户端应使用租约标识符类型0。
In addition to associating client and server messages (along with the msgtype and xid fields, as described in the next section), the Lease Identifier is used to determine which lease a RENEW or RELEASE request refers to. MADCAP servers SHOULD match the Lease Identifier included in a RENEW or RELEASE message with the Lease Identifier used in an initial REQUEST message. If the Lease Identifier does not match, a MADCAP server MUST generate and process a Lease Identifier Not Recognized error in the manner described in section 2.6.
除了关联客户端和服务器消息（以及msgtype和xid字段，如下一节所述），租约标识符还用于确定续订或释放请求所指的租约。MADCAP服务器应将续订或发布消息中包含的租约标识符与初始请求消息中使用的租约标识符相匹配。如果租约标识符不匹配，MADCAP服务器必须按照第2.6节所述的方式生成并处理租约标识符未识别错误。
For conferencing applications, it may be desirable to allow conference participants to modify a lease used for the conference. The Shared Lease Identifier feature code is used to support this requirement. If this feature code was requested by the client and implemented by the server when the lease was allocated, the server SHOULD disable any authentication requirements and allow any client that knows the Lease Identifier to modify the lease.
对于会议应用程序，可能需要允许会议参与者修改用于会议的租约。共享租赁标识符功能代码用于支持此要求。如果此功能代码是在分配租约时由客户端请求并由服务器实现的，则服务器应禁用任何身份验证要求，并允许任何知道租约标识符的客户端修改租约。
As described in the Security Considerations section, MADCAP security is not terribly useful without admission control in the multicast routing infrastructure. However, if MADCAP security is desired when using the Shared Lease Identifier feature, the confidentiality of the Lease Identifier MUST be maintained by encrypting all messages that contain it. A Lease Identifier that includes a long cryptographically random number (at least eight octets in length) MUST be used in this circumstance so that it is not easy to guess the Lease Identifier.
如安全注意事项一节所述，如果在多播路由基础设施中没有许可控制，MADCAP安全性就不是非常有用。但是，如果在使用共享租约标识符功能时需要MADCAP安全性，则必须通过加密包含租约标识符的所有消息来维护租约标识符的机密性。在这种情况下，必须使用包含长密码随机数（长度至少为8个八位字节）的租约标识符，以便不容易猜测租约标识符。
The first octet of a Random Lease Identifier is the Lease Identifier type (0 to indicate Random Lease Identifier). After this come a sequence of octets, which SHOULD represent a long random number (at least 16 octets) from a decent random number generator.
随机租约标识符的第一个八位组是租约标识符类型（0表示随机租约标识符）。然后是一个八位字节序列，它应该代表一个合适的随机数生成器中的一个长随机数（至少16个八位字节）。
A Random Lease Identifier does not include any indication of its length. It is assumed that this may be determined by external means, such as a length field preceding the Lease Identifier.
随机租约标识符不包括其长度的任何指示。假设这可以通过外部手段确定，例如租赁标识符前面的长度字段。
Lease ID
Type Random Number
+---------+-------------...
| 0 |
+---------+-------------...
Lease ID
Type Random Number
+---------+-------------...
| 0 |
+---------+-------------...
The first octet of an Address-Specific Lease Identifier is the Lease Identifier type (1 to indicate Address-Specific Lease Identifier). After this comes a two octet IANA-defined address family number (including those defined in [10]), an address from the specified address family, and a client-specific identifier (such as a sequence number or the current time).
特定于地址的租约标识符的第一个八位组是租约标识符类型（1表示特定于地址的租约标识符）。之后是两个八位字节的IANA定义的地址族编号（包括[10]中定义的编号）、指定地址族中的地址和特定于客户端的标识符（如序列号或当前时间）。
An Address-Specific Lease Identifier does not include any indication of its length. It is assumed that this may be determined by external means, such as a length field preceding the Lease Identifier.
特定于地址的租约标识符不包括其长度的任何指示。假设这可以通过外部手段确定，例如租赁标识符前面的长度字段。
Lease ID Address Family Address Client-specific
Type Number Identifier
+---------+---------+---------+-----...-----+-----...-----+
| 1 | addrfamily | address | cli-spec id |
+---------+---------+---------+-----...-----+-----...-----+
Lease ID Address Family Address Client-specific
Type Number Identifier
+---------+---------+---------+-----...-----+-----...-----+
| 1 | addrfamily | address | cli-spec id |
+---------+---------+---------+-----...-----+-----...-----+
Messages between clients and servers are associated with one another using the Lease Identifier and the xid field. As described in section 2.1.4, the client MUST choose an xid so that it is unlikely that the same combination of xid, msgtype, and Lease Identifier will be used for two different messages within [XID-REUSE-INTERVAL] (even across multiple clients which do not communicate among themselves). The Lease Identifier option, msgtype, and xid field MUST be included in each message sent by the client or the server.
客户端和服务器之间的消息使用租约标识符和xid字段彼此关联。如第2.1.4节所述，客户机必须选择一个xid，以便在[xid-REUSE-INTERVAL]内（甚至在不相互通信的多个客户机之间）不太可能对两个不同的消息使用相同的xid、msgtype和租约标识符组合。客户机或服务器发送的每条消息中都必须包含租约标识符选项、msgtype和xid字段。
The client MUST check the Lease Identifier option and xid field in each incoming message to ensure that they match the Lease Identifier and xid for an outstanding transaction. If not, the message MUST be ignored. The server MUST check the Lease Identifier option and xid field in each incoming message to establish the proper context for the message. If a server cannot process a message because it is invalid for its context, the server MUST generate and process an Invalid Request error, as described in section 2.6. A transaction can be an attempt to allocate a multicast address (consisting of DISCOVER, OFFER, REQUEST, ACK, and NAK messages), an attempt to renew a lease (consisting of RENEW, ACK, and NAK messages), an attempt to release a previously allocated multicast address (consisting of RELEASE, ACK, and NAK messages), or an attempt to acquire configuration parameters (consisting of GETINFO, ACK, and NAK messages).
客户端必须检查每个传入消息中的租约标识符选项和xid字段，以确保它们与未完成事务的租约标识符和xid匹配。如果没有，则必须忽略该消息。服务器必须检查每个传入消息中的租约标识符选项和xid字段，以便为消息建立适当的上下文。如果服务器无法处理消息，因为消息对其上下文无效，则服务器必须生成并处理无效请求错误，如第2.6节所述。事务可以是尝试分配多播地址（包括发现、提供、请求、确认和NAK消息）、尝试续订租约（包括续订、确认和NAK消息）、尝试释放先前分配的多播地址（包括释放、确认和NAK消息），或者尝试获取配置参数（包括GETINFO、ACK和NAK消息）。
If a MADCAP server encounters an error while processing a message, there are two different ways to process this error. If it is clear that the message is not a NAK, the server SHOULD respond with a NAK containing the appropriate Error option. However, the server MAY decide to completely ignore chronic offenders. If the message is a NAK or it is not clear whether the message is a NAK (for instance, the message is garbled or has an incorrect version number), the server SHOULD ignore the message. This avoids NAK loops.
如果MADCAP服务器在处理消息时遇到错误，则有两种不同的方法来处理此错误。如果消息显然不是NAK，则服务器应使用包含适当错误选项的NAK进行响应。但是，服务器可能会决定完全忽略长期违规者。如果消息是NAK或不清楚消息是否是NAK（例如，消息被篡改或版本号不正确），服务器应忽略该消息。这避免了NAK循环。
If a MADCAP client encounters an error while processing a message, it MUST ignore the message.
如果MADCAP客户端在处理消息时遇到错误，则必须忽略该消息。
RFC 2365 [3] provides for dividing the multicast address space into a number of administrative scopes. Routers should be configured so that each scope corresponds to a particular partition of the network into disjoint regions. Messages sent to a multicast address that falls within a certain administrative scope should only be delivered to hosts that have joined that multicast group *and* fall within the same region as the sender. For instance, packets sent to an address in the organization-local scope should only be delivered to hosts that have joined that group and fall within the same organization as the sender.
RFC 2365[3]规定将多播地址空间划分为多个管理范围。路由器的配置应使每个作用域对应于网络中不相交区域的特定分区。发送到某个管理范围内的多播地址的消息只应发送到已加入该多播组*且*与发送方位于同一区域内的主机。例如，发送到组织本地作用域中的地址的数据包只应发送到已加入该组且与发送方属于同一组织的主机。
Different sets of scopes may be in effect at different places in the network and at different times. Before attempting to allocate an address from an administrative scope (other than global or link-level scope, which are always in effect), a MADCAP client SHOULD determine that the scope is in effect at its location at this time. Several techniques that a MADCAP client may use to determine the set of administrative scopes in effect (the scope list) are: manual configuration or configuration via MADCAP (using the Multicast Scope List option).
不同的作用域集可能在网络中的不同位置和不同时间生效。在尝试从管理范围（而不是始终有效的全局或链接级别范围）分配地址之前，MADCAP客户端应确定该范围此时在其位置有效。MADCAP客户端可用于确定有效的管理作用域集（作用域列表）的几种技术是：手动配置或通过MADCAP进行配置（使用多播作用域列表选项）。
If a MADCAP client is unable to determine its scope list using one of these techniques, it MAY temporarily assume a scope list consisting of a single scope. If it is using IPv4, it SHOULD use IPv4 Local Scope (239.255.0.0/16), with a maximum TTL of 16. If it is using IPv6, it SHOULD use SCOP 3, with a maximum hop count of 16. Using this temporary scope list, it MAY attempt to contact a MADCAP server that can provide a scope list for it.
如果MADCAP客户端无法使用这些技术之一确定其作用域列表，它可能会临时假定一个由单个作用域组成的作用域列表。如果使用IPv4，则应使用IPv4本地作用域（239.255.0.0/16），最大TTL为16。如果使用IPv6，则应使用SCOP 3，最大跃点计数为16。使用此临时作用域列表，它可能会尝试联系可以为其提供作用域列表的MADCAP服务器。
When a MADCAP client requests an address with a DISCOVER or REQUEST message, it MUST specify the administrative scope from which the address should be allocated. This scope is indicated with the Multicast Scope option. Likewise, the server MUST include the Multicast Scope option in all OFFER messages and all ACK messages sent in response to REQUEST messages.
当MADCAP客户端使用发现或请求消息请求地址时，它必须指定应从中分配地址的管理范围。此范围由多播范围选项指示。同样，服务器必须在所有提供消息和响应请求消息而发送的所有ACK消息中包含多播作用域选项。
Another way to limit propagation of multicast messages is by using TTL scoping. This technique has several disadvantages in comparison to administratively scoped multicast addresses (as described in [3]), but it is currently in widespread usage.
限制多播消息传播的另一种方法是使用TTL作用域。与管理范围的多播地址（如[3]中所述）相比，该技术有几个缺点，但目前已被广泛使用。
With TTL scoping, areas of the network are designated as scopes. Routers on the edges of these areas are configured with TTL thresholds so that multicast packets are not forwarded unless their
通过TTL作用域，网络区域被指定为作用域。这些区域边缘上的路由器配置有TTL阈值，这样，除非多播数据包被转发，否则不会转发多播数据包
remaining TTL exceeds this threshold. A packet which should be restricted to a given TTL scope should have an initial TTL less than that scope's TTL threshold. Similar techniques may be used with IPv6, using the Hop Count field instead of the TTL field.
剩余TTL超过此阈值。应限制在给定TTL范围内的数据包的初始TTL应小于该范围的TTL阈值。类似的技术可用于IPv6，使用跃点计数字段而不是TTL字段。
MADCAP may be used in an environment where administrative scoping is not in use and TTL scoping is. Under these circumstances, a MADCAP server MAY return a scope list that includes scopes with TTLs less than 255. The MADCAP client MAY then allocate addresses from these scopes, but MUST NOT set the TTL field of any packet sent to such an address to a value greater than the maximum TTL indicated in the scope list. In such an environment, it is recommended that the MADCAP Server Multicast Addresses associated with the IPv4 Local Scope (or SCOP 3 for IPv6) be configured using TTL thresholds so that packets sent to these addresses with TTL of 16 are not sent outside an appropriate boundary. This will allow MADCAP clients to use their default behavior for finding MADCAP servers.
MADCAP可以在不使用管理范围而不使用TTL范围的环境中使用。在这些情况下，MADCAP服务器可能返回一个范围列表，其中包括TTL小于255的范围。MADCAP客户端随后可以从这些作用域分配地址，但不得将发送到该地址的任何数据包的TTL字段设置为大于作用域列表中指示的最大TTL的值。在这种环境中，建议使用TTL阈值配置与IPv4本地作用域（或IPv6的SCOP 3）关联的MADCAP服务器多播地址，以便发送到这些地址的TTL为16的数据包不会发送到适当的边界之外。这将允许MADCAP客户端使用其默认行为来查找MADCAP服务器。
In an environment where administrative scoping is in use, the maximum TTLs in the scope list SHOULD be 255. The admin scope zone boundary routers will prevent leakage of MADCAP packets beyond appropriate limits.
在使用管理作用域的环境中，作用域列表中的最大TTL应为255。管理范围区域边界路由器将防止超出适当限制的MADCAP数据包泄漏。
There are several ways for a MADCAP client to locate a MADCAP server. For instance, the client may be configured with an IP address.
MADCAP客户端有几种方法来定位MADCAP服务器。例如，客户机可以配置IP地址。
The RECOMMENDED technique is for the client to send an GETINFO message to a MADCAP Server Multicast Address and wait for ACK responses. This technique is described in more detail in the next section.
推荐的技术是客户端向MADCAP服务器多播地址发送GETINFO消息并等待ACK响应。下一节将更详细地描述此技术。
Each multicast scope has an associated MADCAP Server Multicast Address. This address has been reserved by the IANA as the address with a relative offset of -1 from the last address of a multicast scope.
每个多播作用域都有一个关联的MADCAP服务器多播地址。IANA已将此地址保留为与多播作用域的最后一个地址相对偏移量为-1的地址。
A MADCAP client looking for servers that can provide multicast allocation services MAY send an GETINFO message to a MADCAP Server Multicast Address. Any MADCAP servers listening to this address SHOULD respond with a unicast ACK message to the client if they wish to offer a response.
寻找能够提供多播分配服务的服务器的MADCAP客户端可以向MADCAP服务器多播地址发送GETINFO消息。任何侦听此地址的MADCAP服务器如果希望提供响应，应向客户端发送单播ACK消息。
The MADCAP Server Multicast Address used by a client MAY be established by configuration. If a client has no such configuration, it SHOULD use the MADCAP Server Multicast Address associated with IPv4 Local Scope (or SCOP 3 for IPv6) with maximum TTL of 16, unless otherwise configured.
客户端使用的MADCAP服务器多播地址可以通过配置来建立。如果客户端没有此类配置，则应使用与IPv4本地作用域（或IPv6的SCOP 3）关联的MADCAP服务器多播地址，最大TTL为16，除非另有配置。
If a client receives no response to a message sent to a MADCAP Server Multicast Address (after retransmission), it MAY send the message to a larger scope and repeat this process as necessary. However, the client MUST NOT send a MADCAP message to the MADCAP Server Multicast Address associated with the global scope.
如果客户端没有收到对发送到MADCAP服务器多播地址的消息的响应（在重新传输之后），它可能会将消息发送到更大的范围，并根据需要重复此过程。但是，客户端不得向与全局作用域关联的MADCAP服务器多播地址发送MADCAP消息。
This technique allows MADCAP servers to provide services for scopes in which they do not reside. However, this is a dangerous and complicated technique and is NOT RECOMMENDED at this time. Therefore, MADCAP clients SHOULD only send multicast messages to the MADCAP Server Multicast Address corresponding to the IPv4 Local Scope (or SCOP 3, if using IPv6), unless configured otherwise.
这种技术允许MADCAP服务器为它们不驻留的作用域提供服务。然而，这是一种危险且复杂的技术，目前不推荐使用。因此，除非另有配置，否则MADCAP客户端应仅向与IPv4本地作用域（或SCOP 3，如果使用IPv6）对应的MADCAP服务器多播地址发送多播消息。
MADCAP servers that wish to provide services for scopes in which they do not reside MUST make special efforts to ensure that their services meet clients' needs for largely conflict-free allocation and accurate scope list information. In particular, coordinating with other servers that provide services for this scope may be difficult. Also, establishing which scope the client is in may be difficult. If a MADCAP server is not prepared to provide services for scopes in which it does not reside, it SHOULD ignore DISCOVER and REQUEST messages whose scope does not match or enclose the scope of the MADCAP Server Multicast Address on which the request was received. It SHOULD also ignore GETINFO messages that are not received on the MADCAP Server Multicast Address for IPv4 Local Scope.
MADCAP服务器希望为其不驻留的作用域提供服务，必须特别努力确保其服务满足客户对基本上无冲突的分配和准确的作用域列表信息的需求。特别是，与为该范围提供服务的其他服务器进行协调可能很困难。此外，确定客户所处的范围可能很困难。如果MADCAP服务器不准备为其未驻留的作用域提供服务，则应忽略作用域不匹配的发现和请求消息，或包含接收请求的MADCAP服务器多播地址的作用域。它还应该忽略在IPv4本地作用域的MADCAP服务器多播地址上未接收到的GETINFO消息。
The Current Time option is used to detect and handle clock skew between MADCAP clients and servers. This option MUST be included in any MADCAP message that includes an absolute time (such as the Start Time option). It MAY be included in any DISCOVER, OFFER, REQUEST, RENEW, or ACK message.
当前时间选项用于检测和处理MADCAP客户端和服务器之间的时钟偏差。此选项必须包含在任何包含绝对时间的MADCAP消息中（例如“开始时间”选项）。它可能包含在任何发现、提供、请求、续订或确认消息中。
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.
时钟偏移是指两个系统的时钟不同步的情况。许多协议（如DHCP）通过使用相对时间来忽略时钟偏移。MADCAP可以使用类似的技术，但由于多播地址的使用方式，这会导致糟糕的情况。
For example, assume that at 1 PM UTC a client whose clock is one hour fast requests a lease for one hour starting in one hour. If we were using relative times for MADCAP, the server, whose clock is set correctly, would reserve a multicast address for 2 to 3 PM UTC and grant the request. If the client was the only one using the lease, everything would be OK. The client would start using the lease in one hour and continue for one hour. This would coincide with the time the server had reserved (although the client would think it was 3 to 4 PM UTC).
例如，假设UTC下午1点，时钟快一小时的客户机请求租用一小时，从一小时后开始。如果我们使用MADCAP的相对时间，则其时钟设置正确的服务器将为UTC下午2到3点保留一个多播地址，并批准该请求。如果客户是唯一使用租约的人，一切都会好起来。客户将在一小时内开始使用租约，然后继续使用一小时。这将与服务器保留的时间一致（尽管客户端认为是UTC下午3到4点）。
However, multicast addresses are usually used by several parties at once. The client would probably use SAP (or some other mechanism for conveying SDP) to advertise a session using the multicast address just leased. SDP uses absolute times, since it may be sent via email, web, or other store-and-forward mechanisms. So the client would advertise the session as running from 3 to 4 PM UTC. Any clients whose clocks are set correctly would use the address during this interval. Since the server only reserved the address from 2 to 3 PM UTC, this might cause the address to be used for multiple sessions simultaneously.
然而，多播地址通常由多个参与方同时使用。客户机可能会使用SAP（或其他传输SDP的机制）来使用刚刚租用的多播地址播发会话。SDP使用绝对时间，因为它可以通过电子邮件、web或其他存储转发机制发送。因此，客户机将公布会话运行时间为UTC下午3点到4点。任何时钟设置正确的客户端都将在此间隔期间使用该地址。由于服务器仅保留UTC下午2点到3点的地址，这可能会导致该地址同时用于多个会话。
MADCAP cannot solve all clock skew problems. That is the domain of NTP [4]. However, it does attempt to detect substantial clock skew between MADCAP clients and servers so that this clock skew does not cause massive collisions in multicast address usage later on.
MADCAP无法解决所有时钟偏移问题。这是NTP的领域[4]。然而，它确实试图检测MADCAP客户端和服务器之间的大量时钟偏差，以便这种时钟偏差不会在以后的多播地址使用中造成大规模冲突。
The Current Time option contains the sender's opinion of the current time in UTC at or about the time the message was assembled. Because of delays in transmission and processing, this value will rarely match the receiver's opinion of the current time at the time the option is processed by the receiver. However, difference greater than a minute or two probably indicate clock skew between the sender and the receiver.
Current Time（当前时间）选项包含发件人对当前时间（UTC）的意见，该时间为邮件汇编时的时间。由于传输和处理中的延迟，此值很少与接收器处理选项时接收器对当前时间的意见相匹配。然而，大于一两分钟的差异可能表明发送方和接收方之间存在时钟偏差。
MADCAP servers SHOULD expect and tolerate a small amount of clock skew with their clients by ensuring that multicast addresses are allocated for an extra period of time [EXTRA-ALLOCATION-TIME] on either side of the lease given to the client. However, large amounts of clock skew require special handling. The value of [EXTRA-ALLOCATION-TIME] MUST be a configurable parameter, since local circumstances may vary. The RECOMMENDED default is one hour.
MADCAP服务器应通过确保在给客户端的租约的任何一侧为多播地址分配额外的一段时间[extra-ALLOCATION-time]，预计并容忍其客户端的少量时钟偏差。然而，大量的时钟偏差需要特殊处理。[EXTRA-ALLOCATION-TIME]的值必须是可配置的参数，因为本地环境可能会有所不同。建议的默认值为一小时。
However, large amounts of clock skew will cause problems later when sessions are advertised. If a MADCAP server detects clock skew greater than [CLOCK-SKEW-ALLOWANCE], it MUST generate and process an Excessive Clock Skew error, as described in section 2.6. The server MAY also log a message. The value of [CLOCK-SKEW-ALLOWANCE] MUST be a configurable parameter, since local circumstances may vary. The
然而，大量的时钟偏差将在以后发布会话时导致问题。如果MADCAP服务器检测到时钟偏差大于[clock-skew-Allowment]，则必须生成并处理过多的时钟偏差错误，如第2.6节所述。服务器还可以记录消息。[CLOCK-SKEW-Allowment]的值必须是一个可配置的参数，因为当地情况可能会有所不同。这个
RECOMMENDED default is 30 minutes.
建议默认值为30分钟。
Each MADCAP client or server MAY implement one or more optional features. Optional features of MADCAP are identified with a two octet feature code.
每个MADCAP客户端或服务器可以实现一个或多个可选功能。MADCAP的可选功能由两个八位字节的功能代码标识。
A MADCAP client MAY request, require, or indicate support for an optional feature by including a Feature List option in a message. For more information about optional features, see the description of the Feature List option.
MADCAP客户端可以通过在消息中包含功能列表选项来请求、要求或指示对可选功能的支持。有关可选功能的详细信息，请参见功能列表选项的说明。
Table 4 lists the feature codes defined at this time and sections 2.13.1 and 2.13.2 describe how these features work.
表4列出了此时定义的功能代码，第2.13.1节和第2.13.2节描述了这些功能的工作原理。
New MADCAP feature codes may only be defined by IETF Consensus, as described in section 5.
如第5节所述，新的MADCAP特征代码只能由IETF协商一致定义。
Feature Code Feature Name
------------ ------------
0 Server Mobility
1 Retry After
2 Shared Lease Identifier
Feature Code Feature Name
------------ ------------
0 Server Mobility
1 Retry After
2 Shared Lease Identifier
Table 4: MADCAP Feature Codes
表4:MADCAP功能部件代码
The Server Mobility feature allows an address allocated on one MADCAP server to be renewed or released on a different MADCAP server. This requires communication and coordination among MADCAP servers. The primary benefits are immunity to the failure of a single MADCAP server and perhaps greater performance through load balancing.
服务器移动性功能允许在一台MADCAP服务器上分配的地址在另一台MADCAP服务器上更新或释放。这需要在MADCAP服务器之间进行通信和协调。主要的好处是不受单个MADCAP服务器故障的影响，并且可能通过负载平衡获得更高的性能。
In order to take advantage of the Server Mobility feature, a MADCAP client must ensure that the feature is implemented by both the server that is used for the original allocation and the server that is used for the renewal or release. The best way to ensure this is to include the Server Mobility feature in the required list of a Feature List option in the REQUEST message used to allocate the address (and the DISCOVER message, if one is used). When the time comes to renew or release the address, the client SHOULD send a unicast RENEW or RELEASE message to the server from which it allocated the address. However, if this server is unavailable, the client MAY send the RENEW or RELEASE message to any other server that includes the Server Mobility feature in its list of supported features. The client can find such a server by (for instance) sending an GETINFO message with
为了利用服务器移动性功能，MADCAP客户端必须确保该功能由用于原始分配的服务器和用于续订或发布的服务器实现。确保这一点的最佳方法是在用于分配地址的请求消息（以及发现消息（如果使用）中的功能列表选项的所需列表中包含服务器移动性功能。当需要续订或释放地址时，客户端应向其分配地址的服务器发送单播续订或释放消息。但是，如果此服务器不可用，则客户端可能会将续订或释放消息发送到其支持的功能列表中包含服务器移动性功能的任何其他服务器。客户端可以通过（例如）发送带有
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.
如果MADCAP客户端在分配地址时不需要此功能，它可能会将此功能包含在功能列表选项的请求列表中，并查看服务器是否将此功能包含在ACK消息中功能列表选项的所需列表中。
Even if the Server Mobility feature is used, there is no guarantee that a server will be available to perform the renewal or release or that the renewal or release will succeed. Server connectivity may have failed, for instance.
即使使用了服务器移动性功能，也不能保证服务器可以执行续订或发布，也不能保证续订或发布会成功。例如，服务器连接可能已失败。
The Retry After feature allows a MADCAP server to ask the MADCAP client to retry its request later, as may be required when allocating large numbers of addresses or allocating addresses for a long period of time.
重试后功能允许MADCAP服务器要求MADCAP客户端稍后重试其请求，这在分配大量地址或长时间分配地址时可能是必需的。
For instance, if a MADCAP client requests 1000 addresses, administrative approval may be required or allocation of more addresses from another MASC domain may be necessary. This may take several hours or several days. If the MADCAP client and server both support the Retry After feature, the MADCAP server can send back an ACK message with a Retry Time option indicating when the addresses may be ready. The client can retry its request after the Retry Time to get the addresses.
例如，如果MADCAP客户端请求1000个地址，则可能需要行政批准，或者可能需要从另一个MASC域分配更多地址。这可能需要几个小时或几天。如果MADCAP客户端和服务器都支持重试后功能，MADCAP服务器可以发送回ACK消息，其中带有重试时间选项，指示地址何时可以就绪。客户端可以在重试时间后重试其请求以获取地址。
If a MADCAP client includes the Retry After feature in the supported list of a Feature List option in a REQUEST message, a MADCAP server that supports the Retry After feature MAY decide to begin a lengthy allocation process. In this case, the MADCAP server will include an empty List of Address Ranges option in its ACK message, a Feature List option that includes the Retry After feature in the required list, and a Retry Time option with a time after which the client should retry the REQUEST.
如果MADCAP客户端在请求消息中的功能列表选项的支持列表中包含重试后功能，则支持重试后功能的MADCAP服务器可能会决定开始一个漫长的分配过程。在这种情况下，MADCAP服务器将在其ACK消息中包含一个空的地址范围列表选项，一个功能列表选项，该选项在所需列表中包含“重试后”功能，以及一个重试时间选项，该选项包含客户端应重试请求的时间。
The client MUST NOT include the Retry After feature in the requested or required list of a Feature List option, since the decision about whether Retry After is desirable should be left to the MADCAP server.
客户机不得在功能列表选项的请求或必需列表中包含“之后重试”功能，因为关于是否需要在之后重试的决定应留给MADCAP服务器。
At some later time (preferably after the time indicated in the Retry Time option), the client SHOULD send a REQUEST message with all the same options as the original REQUEST message (especially the Lease Identifier option), but with a new xid value. The server MAY return a normal ACK or NAK message at this point or it MAY continue the transaction to a later time by including an empty List of Address Ranges option in its ACK message, a Feature List option that includes the Retry After feature in the required list, and a Retry Time option with a later time after which the client should retry the REQUEST.
在稍后的某个时间（最好是在重试时间选项中指示的时间之后），客户端应发送一条请求消息，该消息具有与原始请求消息相同的所有选项（尤其是租约标识符选项），但具有新的xid值。服务器可在此时返回正常ACK或NAK消息，也可通过在其ACK消息中包含空地址范围列表选项（功能列表选项，其中包括所需列表中的重试后功能）将事务继续到稍后时间，以及一个重试时间选项，稍后客户端应重试该请求。
At any point after receiving the initial ACK message with the Retry Time option, the client MAY terminate the allocation process and any accompanying lease by sending to the server performing the allocation (or another server if the Server Mobility feature is also in effect) a RELEASE message with the Lease Identifier included in the original REQUEST message.
在接收到带有重试时间选项的初始ACK消息后的任何时刻，客户端都可以通过发送到执行分配的服务器（或另一台服务器，如果服务器移动性功能也有效）来终止分配过程和任何伴随的租用原始请求消息中包含租约标识符的释放消息。
The Retry After feature may also be used when renewing a lease. In this case, the description above applies except that the client sends a RENEW message instead of a REQUEST message.
续订租约时也可以使用“以后重试”功能。在这种情况下，除客户端发送续订消息而不是请求消息外，上述描述适用。
If a client sends a RENEW message with a Lease Identifier that matches a lease which is currently undergoing allocation with the Retry After feature in response to a REQUEST message, the server MUST generate and process an Invalid Request error in the manner described in section 2.6. Also, if a client sends a RENEW message with a Lease Identifier that matches a lease which is currently undergoing allocation with the Retry After feature in response to a RENEW message, but the options supplied with the two RENEW messages do not match, the server MUST generate and process an Invalid Request error in the manner described in section 2.6.
如果客户端发送的续订消息的租约标识符与当前正在使用重试后功能分配的租约相匹配，以响应请求消息，则服务器必须按照第2.6节所述的方式生成并处理无效请求错误。此外，如果客户端发送一条续订消息，该消息的租约标识符与当前正在进行分配的租约相匹配，并且响应续订消息时使用“重试后”功能，但两条续订消息提供的选项不匹配，服务器必须以第2.6节所述的方式生成并处理无效请求错误。
Note that the Retry After feature may complicate the application API. For this reason, a MADCAP client may request the Retry After feature for some messages and not for others. This should not cause problems for a robust MADCAP server. In general, servers should not expect consistent behavior from clients except as required by this specification. This also applies to clients' expectations.
请注意，重试后功能可能会使应用程序API复杂化。因此，MADCAP客户端可能会对某些消息而不是其他消息请求“重试后”功能。这不会给健壮的MADCAP服务器带来问题。一般来说，服务器不应期望客户端的行为一致，除非本规范另有要求。这也适用于客户的期望。
For conferencing applications, it may be desirable to allow conference participants to modify a lease used for the conference. The Shared Lease Identifier feature code is used to support this requirement.
对于会议应用程序，可能需要允许会议参与者修改用于会议的租约。共享租赁标识符功能代码用于支持此要求。
If this feature code was requested by the client and implemented by the server when the lease was allocated, the server SHOULD disable any authentication requirements pertaining to this lease, allowing any client that knows the Lease Identifier to modify the lease.
如果此功能代码是在分配租约时由客户端请求并由服务器实现的，则服务器应禁用与此租约相关的任何身份验证要求，允许任何知道租约标识符的客户端修改租约。
A MADCAP client wishing to use the Shared Lease Identifier feature should include this feature in the requested or required lists of the Feature List option of a REQUEST message when first allocating the lease. If the feature was required, the server SHOULD try to implement it for this request and include the feature in the required list of the response. If the server can not implement the feature for this request, it MUST generate and process a Required Feature Not Supported error in the manner described in section 2.6. If the feature was requested, the server SHOULD try to implement the feature and include the feature in the required list of the response. However, if the server cannot implement the feature, it may simply skip it.
希望使用共享租约标识符功能的MADCAP客户端在首次分配租约时，应将该功能包括在请求消息的功能列表选项的请求或要求列表中。如果该功能是必需的，服务器应尝试为此请求实现该功能，并将该功能包括在响应的必需列表中。如果服务器无法实现此请求的功能，则必须按照第2.6节中所述的方式生成并处理所需功能不受支持的错误。如果请求了该功能，服务器应尝试实现该功能，并将该功能包括在响应的所需列表中。但是，如果服务器无法实现该功能，它可能会跳过它。
Subsequent requests pertaining to a lease for which the Shared Lease Identifier feature was implemented at allocation time MAY include the Shared Lease Identifier feature in the requested or required lists of the Feature List option. In this case, the server SHOULD try to implement the feature by disabling any authentication requirements pertaining to this lease, allowing any client that knows the Lease Identifier to modify the lease, and including the feature in the required list of the response. If the server cannot implement the feature, it SHOULD skip it if the feature was requested. But if the feature was required and the server cannot implement it, the server MUST generate and process a Required Feature Not Supported error in the manner described in section 2.6.
与在分配时实现共享租赁标识符功能的租赁相关的后续请求可以在功能列表选项的请求或要求列表中包括共享租赁标识符功能。在这种情况下，服务器应通过禁用与此租约相关的任何身份验证要求，允许任何知道租约标识符的客户端修改租约，并将该功能包括在响应的所需列表中，来尝试实现该功能。如果服务器无法实现该功能，则应在请求该功能时跳过该功能。但是，如果该功能是必需的，而服务器无法实现它，则服务器必须以第2.6节所述的方式生成并处理一个必需的功能不受支持的错误。
As described earlier, each MADCAP message includes an options field consisting of a list of tagged parameters that are called "options". All options consist of a two octet option code and a two octet option length, followed by the number of octets specified by the option length.
如前所述，每个MADCAP消息都包含一个选项字段，该字段由一个称为“选项”的标记参数列表组成。所有选项都由两个八位字节选项代码和两个八位字节选项长度组成，后跟选项长度指定的八位字节数。
This section defines a set of option codes for use in MADCAP messages. New options may be defined using the process defined in section 5. The options are listed in numerical order.
本节定义了一组用于MADCAP消息的选项代码。可使用第5节中定义的流程定义新选项。选项按数字顺序列出。
Table 5 summarizes which options are allowed with each message type.
表5总结了每种消息类型允许的选项。
Option GETINFO ACK (in response to GETINFO)
------ ------ ---------------------------
Lease Time MUST NOT MUST NOT
Server Identifier MUST NOT MUST
Lease Identifier MUST MUST
Multicast Scope MUST NOT MUST NOT
Option Request List MUST MUST NOT
Start Time MUST NOT MUST NOT
Number of Addresses
Requested MUST NOT MUST NOT
Requested Language MAY MUST NOT
Multicast Scope List MUST NOT MAY
List of Address Ranges MUST NOT MUST NOT
Current Time MUST NOT MAY
Feature List MAY MAY
Retry Time MUST NOT MUST NOT
Minimum Lease Time MUST NOT MUST NOT
Maximum Start Time MUST NOT MUST NOT
Error MUST NOT MUST NOT
Option 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
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
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
Option NAK
------ ---
Lease Time MUST NOT
Server Identifier MUST
Lease Identifier MUST
Multicast Scope MUST NOT
Option Request List MUST NOT
Start Time MUST NOT
Number of Addresses
Requested MUST NOT
Requested Language MUST NOT
Multicast Scope List MUST NOT
List of Address Ranges MUST NOT
Current Time MUST NOT
Feature List MAY
Retry Time MUST NOT
Minimum Lease Time MUST NOT
Maximum Start Time MUST NOT
Error MUST
Table 5: Options allowed in MADCAP messages
表5:MADCAP消息中允许的选项
The End option marks the end of valid information in the options field. This option MUST be included at the end of the options field in each MADCAP message.
结束选项标记选项字段中有效信息的结束。此选项必须包含在每个MADCAP消息的选项字段末尾。
The code for this option is 0, and its length is 0.
此选项的代码为0，其长度为0。
Code Len
+-----+-----+-----+-----+
| 0 | 0 |
+-----+-----+-----+-----+
Code Len
+-----+-----+-----+-----+
| 0 | 0 |
+-----+-----+-----+-----+
This option is used in a client request (DISCOVER, REQUEST, or RENEW) to allow the client to request a lease time for the multicast address. In a server reply (OFFER or ACK), a MADCAP server uses this option to specify the lease time it is willing to offer.
此选项用于客户端请求（发现、请求或续订），以允许客户端请求多播地址的租用时间。在服务器回复（提供或确认）中，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 |
+-----+-----+-----+-----+-----+-----+-----+-----+
Code Len Lease Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3.3. Server Identifier
3.3. 服务器标识符
This option contains the IP address of a MADCAP server. A two octet address family number (as defined by IANA, including those defined in [10]) is stored first, followed by the address. The address family for this address is not determined by the addrfamily field in the fixed header so that addresses from one family may be allocated while communicating with a server via addresses of another family.
此选项包含MADCAP服务器的IP地址。首先存储两个八位组的地址族编号（由IANA定义，包括[10]中定义的编号），然后存储地址。此地址的地址族不由固定标头中的addrfamily字段确定，因此在通过另一个族的地址与服务器通信时，可以分配一个族的地址。
All messages sent by a MADCAP server MUST include a Server Identifier option with the IP address of the server sending the message.
MADCAP服务器发送的所有邮件必须包含一个服务器标识符选项，其中包含发送邮件的服务器的IP地址。
MADCAP clients MUST include a Server Identifier option in multicast REQUEST messages in order to indicate which OFFER message has been accepted.
MADCAP客户端必须在多播请求消息中包含服务器标识符选项，以指示已接受哪个提供消息。
The code for this option is 2, and its minimum length is 3.
此选项的代码为2，最小长度为3。
Code Len Address Family Address
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 2 | n | family | a1 | ... |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Code Len Address Family Address
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 2 | n | family | a1 | ... |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
This option is used by MADCAP clients to specify a unique lease identifier. For more information about this option and how it is used, see section 2.4.
MADCAP客户端使用此选项指定唯一的租约标识符。有关此选项及其使用方法的更多信息，请参阅第2.4节。
The code for this option is 3, and its minimum length is 1.
此选项的代码为3，最小长度为1。
Code Len Lease Identifier
+-----+-----+-----+-----+-----+-----+---
| 3 | n | i1 | i2 | ...
+-----+-----+-----+-----+-----+-----+---
Code Len Lease Identifier
+-----+-----+-----+-----+-----+-----+---
| 3 | n | i1 | i2 | ...
+-----+-----+-----+-----+-----+-----+---
The multicast scope option is used by the client to indicate the requested multicast scope in a DISCOVER or REQUEST message. It is also used by the MADCAP server to indicate the scope of an assigned address.
客户端使用多播作用域选项在发现或请求消息中指示请求的多播作用域。MADCAP服务器也使用它来指示分配地址的范围。
The client may obtain the scope list through the Multicast Scope List option or using some other means. The Scope ID is the first multicast address in the scope. The address family of the Scope ID is determined by the addrfamily field in the fixed header.
客户端可以通过多播作用域列表选项或使用一些其他方式来获得作用域列表。作用域ID是作用域中的第一个多播地址。作用域ID的地址族由固定标头中的addrfamily字段确定。
The code for this option is 4, and its minimum length is 1.
此选项的代码为4，最小长度为1。
Code Len Scope ID
+-----+-----+-----+-----+-----+-----
| 4 | n | i1 | ...
+-----+-----+-----+-----+-----+-----
Code Len Scope ID
+-----+-----+-----+-----+-----+-----
| 4 | n | i1 | ...
+-----+-----+-----+-----+-----+-----
This option is used by a MADCAP client in an GETINFO message to request that certain options be included in the server's ACK response. The server SHOULD try to include the specified options in its response, but is not required to do so.
MADCAP客户端在GETINFO消息中使用此选项请求在服务器的ACK响应中包含某些选项。服务器应尝试在其响应中包含指定的选项，但不需要这样做。
The format of this option is a list of option codes.
此选项的格式是选项代码列表。
The code for this option is 5 and the minimum length is 2.
此选项的代码为5，最小长度为2。
Code Len Requested Options
+-----+-----+-----+-----+-----+-----+---...
| 5 | n | Option1 |
+-----+-----+-----+-----+-----+-----+---...
Code Len Requested Options
+-----+-----+-----+-----+-----+-----+---...
| 5 | n | Option1 |
+-----+-----+-----+-----+-----+-----+---...
The Start Time option specifies the starting time for a multicast address lease.
开始时间选项指定多播地址租约的开始时间。
A client may include this option in a DISCOVER, RENEW, or REQUEST message to request a multicast address for use at a future time. A server may include this option in an OFFER message or in an ACK in response to REQUEST or RENEW message to indicate that a lease has been granted which starts at a future time.
客户端可以在发现、续订或请求消息中包含此选项，以请求多播地址供将来使用。服务器可将此选项包括在要约消息或ACK中，以响应请求或续订消息，以指示已授予在未来时间开始的租约。
If the Start Time option is present, the IP Address Lease Time option specifies the duration of the lease beginning at the Start Time option value.
如果存在“开始时间”选项，则“IP地址租约时间”选项将指定从“开始时间”选项值开始的租约的持续时间。
If the Start Time option is present, the Current Time option MUST also be present, as described in section 2.12.
如果存在开始时间选项，则当前时间选项也必须存在，如第2.12节所述。
The time value is an unsigned 32 bit integer in network byte order giving the number of seconds since 00:00 UTC, 1st January 1970. This can be converted to an NTP timestamp by adding decimal 2208988800. This time format will not wrap until the year 2106.
时间值是网络字节顺序的无符号32位整数，表示自1970年1月1日UTC 00:00以来的秒数。通过添加十进制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 |
+-----+-----+-----+-----+-----+-----+-----+-----+
Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 6 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
This option specifies the minimum and desired number of addresses requested by the client. It is only used in DISCOVER and REQUEST messages and is only sent by the client.
此选项指定客户端请求的最小和所需地址数。它仅用于发现和请求消息，并且仅由客户端发送。
The minimum and desired number of addresses requested are unsigned 16 bit integers in network byte order. The minimum MUST be less than or equal to the desired number. If a message is received where this is not the case, the MADCAP server MUST generate and process an Invalid Request error in the manner described in section 2.6.
请求的最小和所需地址数为网络字节顺序的无符号16位整数。最小值必须小于或等于所需的数字。如果收到的消息并非如此，则MADCAP服务器必须按照第2.6节所述的方式生成并处理无效请求错误。
The client MAY obtain more than one address either by repeating the protocol for every address or by requesting several addresses at the same time via this option. When the client is requesting only one address, this option SHOULD NOT be included. A MADCAP server
客户端可以通过对每个地址重复协议或通过此选项同时请求多个地址来获得多个地址。当客户端仅请求一个地址时，不应包括此选项。疯狂的服务器
receiving a DISCOVER or REQUEST packet including this option MUST include between the minimum and desired number of addresses in any OFFER or ACK response.
接收包含此选项的发现或请求数据包时，必须在任何报价或ACK响应中包含最小和所需数量的地址。
The code for this option is 7 and the length is 4.
此选项的代码为7，长度为4。
Code Len Minimum Desired
+-----+-----+-----+-----+-----+-----+-----+-----+
| 7 | 4 | min | desired |
+-----+-----+-----+-----+-----+-----+-----+-----+
Code Len Minimum Desired
+-----+-----+-----+-----+-----+-----+-----+-----+
| 7 | 4 | min | desired |
+-----+-----+-----+-----+-----+-----+-----+-----+
This option specifies the language in which the MADCAP client would like strings such as zone names to be returned. It is only included in an GETINFO message sent by the client. It is an RFC 1766 [6] language tag. The proper way to handle this tag with respect to zone names is discussed further in the definition of the Multicast Scope List option.
此选项指定MADCAP客户端希望返回区域名称等字符串的语言。它仅包含在客户端发送的GETINFO消息中。它是一个RFC1766[6]语言标记。在多播作用域列表选项的定义中，将进一步讨论针对区域名称处理此标记的正确方法。
The code for this option is 8 and the minimum length is 0.
此选项的代码为8，最小长度为0。
Code Len Language Tag
+-----+-----+-----+-----+-----+-...-+-----+
| 8 | n | L1 | | Ln |
+-----+-----+-----+-----+-----+-...-+-----+
Code Len Language Tag
+-----+-----+-----+-----+-----+-...-+-----+
| 8 | n | L1 | | Ln |
+-----+-----+-----+-----+-----+-...-+-----+
This option is sent by the server in an ACK message in response to an GETINFO message sent by the client.
此选项由服务器在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消息中未包含请求的语言选项，则MADCAP服务器应返回每个区域的所有区域名称。如果客户端在其GETINFO消息中包含请求的语言选项，则MADCAP服务器必须为每个区域返回不超过一个区域名称。对于每个区域，MADCAP服务器应首先查找与请求的语言标记匹配的区域名称（使用不区分大小写的ASCII比较）。如果任何名称匹配，则应返回其中一个名称。否则，MADCAP服务器应选择另一个要返回的区域名称（如果定义了任何区域名称）。如果所需语言中没有可用的名称，则应优先选择标记为要使用的区域名称。
The code for this option is 9 and the minimum length is 0.
此选项的代码为9，最小长度为0。
The format of the multicast scope list option is:
多播作用域列表选项的格式为：
Code Len Count Scope List
+-----+-----+-----+-----+-----+-----+-...-+-----+
| 9 | p | m | L1 | | Lm |
+-----+-----+-----+-----+-----+-----+-...-+-----+
Code Len Count Scope List
+-----+-----+-----+-----+-----+-----+-...-+-----+
| 9 | p | m | L1 | | Lm |
+-----+-----+-----+-----+-----+-----+-...-+-----+
The scope list is a list of m tuples, where each tuple is of the form:
范围列表是m个元组的列表，其中每个元组的形式如下：
Scope ID Last Address TTL Name Encoded Name List
Count
+---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+
| ... ID ... | ... Last ... | T | n | EN1 | | ENn |
+---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+
Scope ID Last Address TTL Name Encoded Name List
Count
+---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+
| ... ID ... | ... Last ... | T | n | EN1 | | ENn |
+---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+
where Scope ID is the first multicast address in the scope, Last Address is the last multicast address in the scope, TTL is the multicast TTL value for the multicast addresses of the scope, and Name Count is the number of encoded names for this zone (which may be zero). The address family of the Scope ID and Last Address is determined by the addrfamily field in the fixed header. Note that a particular MADCAP server may be allocating addresses out of some subset of the scope. For instance, the addresses in the scope may be divided among several servers in some way.
其中，作用域ID是作用域中的第一个多播地址，Last address是作用域中的最后一个多播地址，TTL是作用域的多播地址的多播TTL值，Name Count是此区域的编码名称数（可能为零）。作用域ID和最后一个地址的地址系列由固定头中的addrfamily字段确定。请注意，特定的MADCAP服务器可能正在分配超出作用域某个子集的地址。例如，作用域中的地址可能以某种方式在多个服务器之间划分。
Each encoded name is of the form
每个编码的名称都是
Name Lang Language Tag Name Name
Flags Length Length
+-----+-----+-----+-...-+-----+-----+-----+-...-+-----+
| F | q | L1 | | Lq | r | N1 | | Nr |
+-----+-----+-----+-...-+-----+-----+-----+-...-+-----+
Name Lang Language Tag Name Name
Flags Length Length
+-----+-----+-----+-...-+-----+-----+-----+-...-+-----+
| F | q | L1 | | Lq | r | N1 | | Nr |
+-----+-----+-----+-...-+-----+-----+-----+-...-+-----+
where Name Flags is a flags field with flags defined below, Lang Length is the length of the Language Tag in octets (which MUST NOT be zero), Language Tag is a language tag indicating the language of the zone name (as described in [6]), Name Length is the length of the Name in octets (which MUST NOT be zero), and Name is a UTF-8 [5] string indicating the name given to the scope zone.
其中，Name Flags是一个带有以下定义的标志的标志字段，Lang Length是以八位字节为单位的语言标记的长度（不得为零），Language Tag是一个表示区域名称语言的语言标记（如[6]所述），Name Length是以八位字节为单位的名称长度（不得为零），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.
如果在所需语言中没有可用名称，则应使用以下名称，则会设置名称标志字段的高位。否则，该位被清除。八位字节中的所有剩余位应设置为零，并且必须忽略。
The Scope IDs of entries in the list MUST be unique and the scopes SHOULD be listed from smallest (topologically speaking) to largest. This makes it easier to display a consistent user interface, with scopes usually keeping the same order. However, scopes may not be strictly nested. In this circumstance, there is no strict ordering from smallest to largest and the server must use another technique for ordering the scope list.
列表中条目的范围ID必须是唯一的，并且范围应从最小（从拓扑角度）到最大列出。这使得显示一致的用户界面更加容易，作用域通常保持相同的顺序。但是，作用域可能不是严格嵌套的。在这种情况下，没有从最小到最大的严格排序，服务器必须使用另一种技术对作用域列表进行排序。
Example:
例子：
There are two scopes supported by the multicast address allocation server: Inside abcd.com with addresses 239.192.0.0-239.195.255.255, and world with addresses 224.0.1.0-238.255.255.255. Then this option will be given as:
多播地址分配服务器支持两个作用域：地址为239.192.0.0-239.195.255.255的abcd.com内部和地址为224.0.1.0-238.255.255的world。然后，该选项将被指定为：
Code Len Count
+-----+-----+-----+-----+-----+...
| 9 | 51 | 2 |
+-----+-----+-----+-----+-----+...
Code Len Count
+-----+-----+-----+-----+-----+...
| 9 | 51 | 2 |
+-----+-----+-----+-----+-----+...
Scope ID Last Address TTL Name Name Lang Language
Count Flags Length Tag
+---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
|239|192| 0 | 0 |239|195|255|255|10 | 1 | 128 | 2 | en |
+---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
Scope ID Last Address TTL Name Name Lang Language
Count Flags Length Tag
+---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
|239|192| 0 | 0 |239|195|255|255|10 | 1 | 128 | 2 | en |
+---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
Name
Length Name
+------+--+--+-...-+--+--+...
| 15 | Inside abcd.com |
+------+--+--+-...-+--+--+...
Name
Length Name
+------+--+--+-...-+--+--+...
| 15 | Inside abcd.com |
+------+--+--+-...-+--+--+...
Scope ID Last Address TTL Name Name Lang Language
Count Flags Length Tag
+---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
|224| 0 | 1 | 0 |238|255|255|255|16 | 1 | 128 | 2 | en |
+---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
Scope ID Last Address TTL Name Name Lang Language
Count Flags Length Tag
+---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
|224| 0 | 1 | 0 |238|255|255|255|16 | 1 | 128 | 2 | en |
+---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
Name
Length Name
+------+--...--+
| 5 | world |
+------+--...--+
Name
Length Name
+------+--...--+
| 5 | world |
+------+--...--+
This option is used by the server to provide the list of all the address ranges allocated to the client.
服务器使用此选项提供分配给客户端的所有地址范围的列表。
This option is also used by the client when requesting a lease for a specific set of addresses. This feature should be needed only rarely, such as when a lease is accidentally allowed to expire and it needs to be reallocated.
客户端在请求租用特定地址集时也会使用此选项。只有在很少的情况下才需要此功能，例如当租约意外过期并且需要重新分配时。
The address family of the addresses is determined by the addrfamily field.
地址的地址族由addrfamily字段确定。
The code for this option is 10 and the minimum length is 0.
此选项的代码为10，最小长度为0。
Code Len Address Range List
+-----+-----+-----+-----+-----+-----+-...-+-----+
| 10 | n | L1 | L2 | | Ln |
+-----+-----+-----+-----+-----+-----+-...-+-----+
Code Len Address Range List
+-----+-----+-----+-----+-----+-----+-...-+-----+
| 10 | n | L1 | L2 | | Ln |
+-----+-----+-----+-----+-----+-----+-...-+-----+
where the Address Range List is of the following format.
其中地址范围列表的格式如下。
StartAddress1 BlockSize1 StartAddress2 BlockSize2 ...
+---+---+---+---+---+---+---+---+---+---+---+---+--...--+
| ... S1 ... |B11|B12| ... S2 ... |B21|B22| |
+---+---+---+---+---+---+---+---+---+---+---+---+--...--+
StartAddress1 BlockSize1 StartAddress2 BlockSize2 ...
+---+---+---+---+---+---+---+---+---+---+---+---+--...--+
| ... S1 ... |B11|B12| ... S2 ... |B21|B22| |
+---+---+---+---+---+---+---+---+---+---+---+---+--...--+
This option is used to express what the sender thinks the current time is. This is useful for detecting clock skew. This option MUST be included if the Start Time or Maximum Start Time options are used, as described in section 2.12.
此选项用于表示发件人认为当前时间是什么。这对于检测时钟偏移非常有用。如第2.12节所述，如果使用启动时间或最大启动时间选项，则必须包括该选项。
The time value is an unsigned 32 bit integer in network byte order giving the number of seconds since 00:00 UTC, 1st January 1970. This can be converted to an NTP [4] timestamp by adding decimal 2208988800. This time format will not wrap until the year 2106.
时间值是网络字节顺序的无符号32位整数，表示自1970年1月1日UTC 00:00以来的秒数。通过添加十进制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 |
+-----+-----+-----+-----+-----+-----+-----+-----+
Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 11 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
This option lists optional MADCAP features supported, requested, or required, by the sender. This option MAY be included in any message sent by a MADCAP server or client.
此选项列出发件人支持、请求或要求的可选MADCAP功能。此选项可能包含在MADCAP服务器或客户端发送的任何消息中。
Optional features of MADCAP are identified with a two octet feature code. New MADCAP feature codes may only be defined by IETF Consensus, as described in section 5.
MADCAP的可选功能由两个八位字节的功能代码标识。如第5节所述，新的MADCAP特征代码只能由IETF协商一致定义。
The Feature List option consists of three separate lists: supported features, requested features, and required features. Each list consists of an unordered list of feature codes. The supported list is used by MADCAP clients or servers to indicate the features that the sender supports. The requested and required lists are used by MADCAP clients to indicate which features are requested of or required from a MADCAP server. The required list is used by MADCAP servers to indicate which features were implemented by the MADCAP server in processing this message. Messages sent by MADCAP servers MUST NOT include any feature codes in the requested list.
功能列表选项由三个单独的列表组成：支持的功能、请求的功能和必需的功能。每个列表由无序的特征代码列表组成。MADCAP客户端或服务器使用受支持列表来指示发件人支持的功能。MADCAP客户端使用请求和必需列表来指示MADCAP服务器请求或需要哪些功能。MADCAP服务器使用所需列表来指示MADCAP服务器在处理此消息时实现了哪些功能。MADCAP服务器发送的邮件不得在请求的列表中包含任何功能代码。
If a MADCAP client includes the Feature List option in a message, it MAY include features in any of the lists: supported, requested, and required. If a MADCAP server receives a message containing the Feature List option and it does not support all of the features in the required list, it MUST generate and process a Required Feature Not Supported error in the manner described in section 2.6. If the server supports all of the features in the required list, it MUST implement them as appropriate for this message. It SHOULD try to implement the features in the requested list and it MAY implement any of the features in the supported list. If an optional feature (such as Retry After) is not included in any part of the Feature List option included in the client's message (or if the client does not include a Feature List option in its message), the server MUST NOT use that feature in its response.
如果MADCAP客户端在消息中包含功能列表选项，则它可能会在任何列表中包含功能：支持的、请求的和必需的。如果MADCAP服务器接收到包含功能列表选项的消息，并且它不支持所需列表中的所有功能，则它必须以第2.6节所述的方式生成并处理所需功能不受支持的错误。如果服务器支持所需列表中的所有功能，则必须针对此消息实施相应的功能。它应该尝试实现请求列表中的功能，并且可以实现支持列表中的任何功能。如果可选功能（如重试后）未包含在客户端消息中包含的功能列表选项的任何部分中（或者如果客户端消息中未包含功能列表选项），则服务器不得在其响应中使用该功能。
If a MADCAP server does respond to a client's message that includes a Feature List option, the server MUST include a Feature List option with a supported features list that lists the features that it supports, a required features list that lists the features that it implemented in responding to this message (which must be included in the supported features list of the client's Feature List option), and an empty requested features list.
如果MADCAP服务器确实响应了包含功能列表选项的客户端消息，则服务器必须包含功能列表选项，其中支持的功能列表列出了它支持的功能，必需的功能列表列出了它在响应此消息时实现的功能（必须包含在客户端功能列表选项的支持功能列表中），以及空的请求功能列表。
The code for this option is 12 and the minimum length is 6.
此选项的代码为12，最小长度为6。
Code Len Supported Requested Required
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 12 | n | FL1 | FL2 | FL3 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Code Len Supported Requested Required
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 12 | n | FL1 | FL2 | FL3 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
where each of the Feature Lists is of the following format:
其中，每个要素列表的格式如下：
Feature Feature Feature
Count Code 1 Code m
+-----+-----+-----+-----+-...-+-----+-----+
| m | FC1 | | FCm |
+-----+-----+-----+-----+-...-+-----+-----+
Feature Feature Feature
Count Code 1 Code m
+-----+-----+-----+-----+-...-+-----+-----+
| m | FC1 | | FCm |
+-----+-----+-----+-----+-...-+-----+-----+
The Retry Time option specifies the time at which a client should retry a REQUEST or RENEW message when using the Retry After feature.
重试时间选项指定在使用“重试后”功能时客户端应重试请求或续订消息的时间。
This option should only be sent by a MADCAP server in an ACK when responding to a REQUEST or RENEW message that includes the Retry After feature in the supported, requested, or required list. For more discussion of Retry After, see section 2.13.2.
此选项仅应由MADCAP服务器在应答请求或续订消息时在ACK中发送，该请求或续订消息包括支持、请求或必需列表中的重试后功能。有关重试后的更多讨论，请参阅第2.13.2节。
If the Retry Time option is present, the Current Time option MUST also be present.
如果存在重试时间选项，则当前时间选项也必须存在。
The time value is an unsigned 32 bit integer in network byte order giving the number of seconds since 00:00 UTC, 1st January 1970. This can be converted to an NTP timestamp by adding decimal 2208988800. This time format will not wrap until the year 2106.
时间值是网络字节顺序的无符号32位整数，表示自1970年1月1日UTC 00:00以来的秒数。通过添加十进制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 |
+-----+-----+-----+-----+-----+-----+-----+-----+
Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 13 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
This option is used in a client request (DISCOVER, REQUEST, or RENEW) to allow the client to specify a minimum lease time for the multicast address. If a server cannot meet this minimum lease time, it MUST generate and process a Valid Request Could Not Be Completed error in the manner described in section 2.6.
此选项用于客户端请求（发现、请求或续订），以允许客户端为多播地址指定最短租用时间。如果服务器无法满足此最短租用时间，则必须按照第2.6节所述的方式生成并处理有效的“无法完成请求”错误。
The time is in units of seconds, and is specified as a 32-bit unsigned integer.
时间以秒为单位，并指定为32位无符号整数。
The code for this option is 14, and its length is 4.
此选项的代码为14，长度为4。
Code Len Lease Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 14 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
Code Len Lease Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 14 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
The Maximum Start Time option specifies the latest starting time that the client is willing to accept for a multicast address lease.
最大开始时间选项指定客户端愿意接受多播地址租约的最新开始时间。
A client may include this option in a DISCOVER, RENEW, or REQUEST message to specify that it does not want to receive a lease with a starting time later than the specified value. If a server cannot meet this maximum start time, it MUST generate and process a Valid Request Could Not Be Completed error in the manner described in section 2.6.
客户端可以在发现、续订或请求消息中包含此选项，以指定它不希望接收开始时间晚于指定值的租约。如果服务器无法满足此最长启动时间，则必须以第2.6节中描述的方式生成并处理有效的请求无法完成错误。
If the Maximum Start Time option is present, the Current Time option MUST also be present, as described in section 2.12.
如第2.12节所述，如果存在最大启动时间选项，则当前时间选项也必须存在。
The time value is an unsigned 32 bit integer in network byte order giving the number of seconds since 00:00 UTC, 1st January 1970. This can be converted to an NTP timestamp by adding decimal 2208988800. This time format will not wrap until the year 2106.
时间值是网络字节顺序的无符号32位整数，表示自1970年1月1日UTC 00:00以来的秒数。通过添加十进制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 |
+-----+-----+-----+-----+-----+-----+-----+-----+
Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 15 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
A MADCAP server includes this option in a NAK message to indicate why the request failed. A MADCAP server MUST include an Error option in each NAK message.
MADCAP服务器在NAK消息中包含此选项，以指示请求失败的原因。MADCAP服务器必须在每个NAK消息中包含错误选项。
The first two octets of an Error option contain a MADCAP error code. Several MADCAP error codes are defined later in this section. New MADCAP error codes may only be defined by IETF Consensus, as described in section 5.
错误选项的前两个八位字节包含MADCAP错误代码。本节后面将定义几个MADCAP错误代码。新的MADCAP错误代码只能由IETF协商一致定义，如第5节所述。
Any remaining octets in the Error option contain extra data about the error. The format of this data depends on the error code. The definition of a MADCAP error code must include a definition of the extra data to be included with that error code.
错误选项中的任何剩余八位字节都包含有关错误的额外数据。此数据的格式取决于错误代码。MADCAP错误代码的定义必须包含该错误代码所包含的额外数据的定义。
A client that receives a NAK message containing an Error option MAY log or display a message indicating the error code and extra data received. The client MUST NOT retransmit a message once a NAK response to that message has been received. The client MAY adjust the message to correct the error and send the corrected message or send a message to a different server.
接收包含错误选项的NAK消息的客户端可以记录或显示指示错误代码和接收到的额外数据的消息。一旦收到对消息的NAK响应，客户端不得重新传输该消息。客户端可以调整消息以更正错误，并发送更正后的消息或将消息发送到其他服务器。
The code for this option is 16, and the minimum length is 2.
此选项的代码为16，最小长度为2。
Code Len Error Code Extra Data
+-----+-----+-----+-----+-----+-----+-----+-----+ ...
| 16 | n | ecode | d1 d2
+-----+-----+-----+-----+-----+-----+-----+-----+ ...
Code Len Error Code Extra Data
+-----+-----+-----+-----+-----+-----+-----+-----+ ...
| 16 | n | ecode | d1 d2
+-----+-----+-----+-----+-----+-----+-----+-----+ ...
MADCAP error code 0 indicates that the request was valid, but could not be completed with the available addresses and the current configuration. The extra data is a two octet option code indicating which option caused the problem. A value of 0xFFFF indicates that the problem was not with a specific option.
MADCAP错误代码0表示请求有效，但无法使用可用地址和当前配置完成。额外的数据是一个两个八位字节的选项代码，指示是哪个选项导致了问题。值0xFFFF表示问题不在于特定选项。
MADCAP error code 1 indicates that the request was malformed or invalid in some other manner. The extra data is a two octet option code indicating which option caused the problem. A value of 0xFFFF indicates that the problem was not with a specific option.
MADCAP错误代码1表示请求格式错误或以其他方式无效。额外的数据是一个两个八位字节的选项代码，指示是哪个选项导致了问题。值0xFFFF表示问题不在于特定选项。
MADCAP error code 2 indicates excessive clock skew (see section 2.12). The extra data consists of a four octet time value representing the server's idea of the current time, an unsigned 32 bit integer in network byte order giving the number of seconds since 00:00 UTC, 1st January 1970. This can be converted to an NTP timestamp by adding decimal 2208988800. This time format will not wrap until the year 2106.
MADCAP错误代码2表示过度的时钟偏差（见第2.12节）。额外的数据包括一个表示服务器当前时间概念的四个八位时间值，一个网络字节顺序的无符号32位整数，表示自1970年1月1日UTC 00:00以来的秒数。通过添加十进制2208988800，可以将其转换为NTP时间戳。这个时间格式要到2106年才会换行。
MADCAP error code 3 indicates that the Lease Identifier was not recognized (usually in response to a RENEW or RELEASE message). There is no extra data.
MADCAP错误代码3表示无法识别租约标识符（通常响应续订或释放消息）。没有额外的数据。
MADCAP error code 4 indicates that at least one feature included in the required list of the Feature List option is not supported. The extra data contains a list of the feature codes in the required list that are not supported.
MADCAP错误代码4表示功能列表选项的必需列表中至少包含一个功能不受支持。额外数据包含所需列表中不受支持的功能部件代码列表。
MADCAP error codes 1024-2047 are reserved for experimental use. The format of the extra data included with these error codes is not defined.
MADCAP错误代码1024-2047保留供实验使用。未定义这些错误代码中包含的额外数据的格式。
MADCAP has relatively basic security requirements. At present there is no way of enforcing authorized use of multicast addresses in the multicast routing/management protocols. Therefore, it is not possible to identify unauthorized use of multicast address by an adversary. Moreover, a multicast address allocated to a user/system can be used by other systems without violating terms of the multicast address allocation. For example, a system may reserve an address to be used for a work group session where each and every member of the work group is allowed to transmit packets using the allocated group address. In other words, the multicast address allocation protocol does not dictate how the address should be used, it only dictates the time period for which it can be used and who gets to release it or renew it. When an address is allocated to a system/user, it basically means that no other user/system (most likely) will be allocated that address for the time period, without any restrictions on its use.
MADCAP有相对基本的安全要求。目前，在多播路由/管理协议中没有强制授权使用多播地址的方法。因此，不可能识别对手未经授权使用多播地址。此外，分配给用户/系统的多播地址可以被其他系统使用，而不会违反多播地址分配的条款。例如，系统可以保留用于工作组会话的地址，其中允许工作组的每个成员使用分配的组地址发送分组。换句话说，多播地址分配协议并不规定如何使用该地址，它只规定可以使用该地址的时间段以及谁可以释放或更新该地址。当一个地址被分配给一个系统/用户时，它基本上意味着没有其他用户/系统（最有可能）在该时间段内被分配该地址，对其使用没有任何限制。
To protect against rogue MADCAP servers (mis-configured servers and intentional), clients in certain situations would like to authenticate the server. Similarly, for auditing or book-keeping purposes, the server may want to authenticate clients. Moreover, in some cases, the server may have certain policies in place to restrict the number of addresses that are allocated to a system or a user. This feature is of much value when a well behaved but naive user or client requests a large number of addresses, and therefore, inadvertently impacts other users or systems. Therefore, an administrator may want to exert a limited amount of control based on the client identification. The client identification could be based
为了防止恶意的MADCAP服务器（配置错误的服务器和故意的），在某些情况下，客户端希望对服务器进行身份验证。类似地，出于审计或簿记目的，服务器可能希望对客户端进行身份验证。此外，在某些情况下，服务器可能具有某些适当的策略来限制分配给系统或用户的地址数量。当行为良好但幼稚的用户或客户端请求大量地址时，此功能非常有用，因此会无意中影响其他用户或系统。因此，管理员可能希望基于客户端标识施加有限的控制。客户身份可以基于
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消息）事先知道特定用户在特定时间段和范围内请求了大量地址，则他可能能够猜出此类请求背后的目的并以攻击为目标。当使用共享租约标识符功能时，保护MADCAP消息的机密性变得更加重要。此外，将来可能会向协议中添加具有更高保密性要求的功能。
The IPSEC protocol [8] meets client/server identification and integrity protection requirements stated above, requires no modification to the MADCAP protocol, and leverages extensive work in IETF and industry. Therefore, when security is a strong requirement, IPSEC SHOULD be used for protecting all the unicast messages of MADCAP protocol. When IPSEC based security is in use, all the multicast packets except GETINFO MUST be dropped by the MADCAP server. The prevalent implementations of IPSEC support client identification in form of system identification and do not support user identification. However, when desired, IPSEC with appropriate API's may be required to support user identification.
IPSEC协议[8]满足上述客户机/服务器标识和完整性保护要求，不需要修改MADCAP协议，并利用IETF和行业中的大量工作。因此，当安全性要求很高时，应该使用IPSEC来保护MADCAP协议的所有单播消息。当使用基于IPSEC的安全性时，MADCAP服务器必须丢弃除GETINFO之外的所有多播数据包。IPSEC的流行实现支持系统标识形式的客户端标识，不支持用户标识。但是，如果需要，可能需要具有适当API的IPSEC来支持用户标识。
This document defines several number spaces (MADCAP options, MADCAP message types, MADCAP Lease Identifier types, MADCAP features, and MADCAP error codes). For all of these number spaces, certain values are defined in this specification. New values may only be defined by IETF Consensus, as described in [7]. Basically, this means that they are defined by RFCs approved by the IESG.
本文档定义了几个数字空间（MADCAP选项、MADCAP消息类型、MADCAP租约标识符类型、MADCAP功能和MADCAP错误代码）。对于所有这些数字空间，本规范中定义了某些值。如[7]所述，新值只能由IETF共识定义。基本上，这意味着它们由IESG批准的RFC定义。
The authors would like to thank Rajeev Byrisetty, Steve Deering, Peter Ford, Mark Handley, Van Jacobson, David Oran, Thomas Pfenning, Dave Thaler, Ramesh Vyaghrapuri and the participants of the IETF for their assistance with this protocol.
作者感谢Rajeev Byrisetty、Steve Deering、Peter Ford、Mark Handley、Van Jacobson、David Oran、Thomas Pfenning、Dave Thaler、Ramesh Vyaghrapuri和IETF参与者对本协议的帮助。
Much of this document is based on [1] and [2]. The authors of this document would like to express their gratitude to the authors of these previous works. Any errors in this document are solely the fault of the authors of this document.
本文档的大部分内容基于[1]和[2]。本文件的作者谨向这些先前作品的作者表示感谢。本文件中的任何错误都是本文件作者的过错。
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[1] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[2] Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[3] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[3] Meyer，D.，“管理范围的IP多播”，BCP 23，RFC 2365，1998年7月。
[4] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[4] Mills，D.，“网络时间协议（第3版）规范、实施和分析”，RFC13051992年3月。
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[5] “UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
[6] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[6] Alvestrand，H.，“语言识别标签”，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注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[8] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[8] Atkinson，R.和S.Kent，“互联网协议的安全架构”，RFC 2401，1998年11月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[10] Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
[11] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[11] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[12] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[13] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[13] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[14] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[14] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
Stephen R. Hanna Sun Microsystems, Inc. One Network Drive Burlington, MA 01803
Stephen R.Hanna Sun Microsystems，Inc.马萨诸塞州伯灵顿市一路网络驱动器01803
Phone: +1.781.442.0166
EMail: steve.hanna@sun.com
Phone: +1.781.442.0166
EMail: steve.hanna@sun.com
Baiju V. Patel Intel Corp. Mail Stop: AG2-201 5200 NE Elam Young Parkway Hillsboro, OR 97124
Baiju诉Patel Intel Corp.邮递站：AG2-201 5200 NE Elam Young Parkway Hillsboro，或97124
Phone: 503 696 8192 EMail: baiju.v.patel@intel.com
电话：5036968192电子邮件：baiju.v。patel@intel.com
Munil Shah Microsoft Corporation One Microsoft Way Redmond, WA 98052
Munil Shah微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: 425 703 3924 EMail: munils@microsoft.com
电话：425 703 3924电子邮件：munils@microsoft.com
APPENDIX A: Examples
附录A：示例
This appendix includes several examples of typical MADCAP protocol exchanges.
本附录包括几个典型MADCAP协议交换示例。
In this example, a MADCAP client wants to determine the scope list in effect. The client is using IPv4, so it starts by multicasting an GETINFO packet to the MADCAP Server Multicast Address corresponding to IPv4 Local Scope. This packet includes the Lease Identifier option, an Option Request List including the Multicast Scope List option code, and a Requested Language option containing the string "en", since the client is configured to prefer the English language.
在本例中，MADCAP客户端希望确定有效的范围列表。客户端正在使用IPv4，因此它首先将GETINFO数据包多播到与IPv4本地作用域对应的MADCAP服务器多播地址。该分组包括租赁标识符选项、包括多播作用域列表选项代码的选项请求列表以及包含字符串“en”的请求语言选项，因为客户端被配置为更喜欢英语。
Two MADCAP servers respond by sending ACK messages. These ACK messages include the Lease Identifier option and xid supplied by the client, the server's Server Identifier, and the Multicast Scope List with one name per scope (the one that most closely matches the language tag "en").
两个MADCAP服务器通过发送ACK消息进行响应。这些ACK消息包括客户机提供的租约标识符选项和xid、服务器的服务器标识符以及每个作用域有一个名称的多播作用域列表（与语言标记“en”最匹配的名称）。
The following figure illustrates this exchange.
下图说明了此交换。
Server Client Server
v v v
| | |
| | |
| _____________/|\_____________ |
|/ GETINFO | GETINFO \|
| | |
| | |
|\ | ____________/|
| \_________ | / ACK |
| ACK \ |/ |
| \ | |
| | |
v v v
Server Client Server
v v v
| | |
| | |
| _____________/|\_____________ |
|/ GETINFO | GETINFO \|
| | |
| | |
|\ | ____________/|
| \_________ | / ACK |
| ACK \ |/ |
| \ | |
| | |
v v v
Figure 2: Timeline diagram of messages exchanged in Multicast Scope List Discovery example
图2：多播作用域列表发现示例中交换的消息的时间线图
In this example, the MADCAP client wants to allocate a multicast address from the global scope for use during the next two hours.
在本例中，MADCAP客户端希望从全局范围分配一个多播地址，以便在接下来的两个小时内使用。
The client begins by multicasting a DISCOVER packet to the MADCAP Server Multicast Address associated with IPv4 Local Scope. This packet includes the Lease Time, Lease Identifier, and Multicast Scope options.
客户端首先将发现数据包多播到与IPv4本地作用域关联的MADCAP服务器多播地址。此数据包包括租约时间、租约标识符和多播作用域选项。
Any servers that receive the DISCOVER packet and can satisfy this request temporarily reserve an address for the client and unicast an OFFER packet to the client. These packets contain the Lease Time, Server Identifier, Lease Identifier, and Multicast Scope options.
任何接收到发现数据包并能够满足此请求的服务器都会临时为客户端保留一个地址，并向客户端单播一个提供数据包。这些数据包包含租约时间、服务器标识符、租约标识符和多播作用域选项。
After an appropriate delay, the client multicasts a REQUEST packet to the MADCAP Server Multicast Address. This packet contains all of the options included in the DISCOVER packet, but also includes the Server Identifier option, indicating which server it has selected for the request.
在适当的延迟之后，客户端将请求数据包多播到MADCAP服务器多播地址。此数据包包含DISCOVER数据包中包含的所有选项，但也包含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数据包，其中包含报价数据包中包含的选项，以及一个列出分配地址的地址范围选项列表。所有其他发送了提供数据包的服务器都停止为客户端保留地址，而忘记了整个交换。
The client now has a two hour "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 new DISCOVER message.
如果客户端没有收到来自服务器的ACK，它将在一段时间内重新传输其请求数据包。如果仍然没有收到响应，它将以一条新的发现消息重新开始。
The following figure illustrates this exchange.
下图说明了此交换。
Server Client Server
(not selected) (selected)
v v v
| | |
|Begin multicast address request|
| | |
| _____________/|\_____________ |
|/ DISCOVER | DISCOVER \|
| | |
Reserves | Reserves
Address | Address
| | |
|\ | ____________/|
| \_________ | / OFFER |
| OFFER \ |/ |
| \ | |
| Collects replies |
| \| |
| Selects Server |
| | |
| _____________/|\_____________ |
|/ REQUEST | REQUEST \|
| | |
| | Commits address
| | |
| | _____________/|
| |/ ACK |
| | |
| assignment complete |
| | |
v v v
Server Client Server
(not selected) (selected)
v v v
| | |
|Begin multicast address request|
| | |
| _____________/|\_____________ |
|/ DISCOVER | DISCOVER \|
| | |
Reserves | Reserves
Address | Address
| | |
|\ | ____________/|
| \_________ | / OFFER |
| OFFER \ |/ |
| \ | |
| Collects replies |
| \| |
| Selects Server |
| | |
| _____________/|\_____________ |
|/ REQUEST | REQUEST \|
| | |
| | Commits address
| | |
| | _____________/|
| |/ ACK |
| | |
| assignment complete |
| | |
v v v
Figure 3: Timeline diagram of messages exchanged in Multicast Address Allocation example
图3：多播地址分配示例中交换的消息的时间线图
This is a continuation of the previous example. The client has already allocated a multicast address from the global scope for use during the next two hours. Half way through this two hour period, it decides that it wants to extend its lease for another hour.
这是上一个示例的延续。客户端已经从全局范围分配了一个多播地址，以便在接下来的两个小时内使用。在这两个小时的一半时间里，它决定将租赁期再延长一个小时。
The client unicasts a RENEW packet to the server from which it allocated the address. This packet includes the Lease Time and Lease Identifier options. The Lease Identifier matches the one used for the original allocation. The time included in the Lease Time is two
客户机将续订数据包单播到其分配地址的服务器。此数据包包括租约时间和租约标识符选项。租约标识符与用于原始分配的标识符匹配。租赁时间中包含的时间为两个
hours, since the client wants the lease to expire two hours from the current time.
小时，因为客户希望租约在当前时间两小时后到期。
The server responds with an ACK packet indicating that the lease extension has been granted. This packet includes the Lease Time, Server Identifier, Lease Identifier, Multicast Scope, and List of Address Ranges options.
服务器用ACK数据包进行响应，该数据包指示已授予租约扩展。此数据包包括租用时间、服务器标识符、租用标识符、多播作用域和地址范围选项列表。
If the server did not want to grant the requested lease extension, it would have responded with a NAK packet with the Lease Identifier option.
如果服务器不想授予请求的租约扩展，它将使用带有租约标识符选项的NAK数据包进行响应。
The following figure illustrates this exchange.
下图说明了此交换。
Client Server
v v
| |
|\_____________ |
| RENEW \|
| |
| Extends lease
| |
| _____________/|
|/ ACK |
| |
| |
v v
Client Server
v v
| |
|\_____________ |
| RENEW \|
| |
| Extends lease
| |
| _____________/|
|/ ACK |
| |
| |
v v
Figure 4: Timeline diagram of messages exchanged in Lease Extension example
图4：租约扩展示例中交换的消息的时间线图
This is a continuation of the previous example. The client has already allocated a multicast address and extended its lease for another two hours. Half an hour later, the client finishes its use of the multicast address and wants to release it so it can be reused.
这是上一个示例的延续。客户端已经分配了一个多播地址，并将其租约再延长了两个小时。半小时后，客户端完成了对多播地址的使用，并希望将其释放，以便可以重用。
The client unicasts a RELEASE packet to the server from which it allocated the address. This packet includes the Lease Identifier option. The Lease Identifier matches the one used for the original allocation. When the server receives this packet, it cancels the client's lease on the address and sends an ACK packet to the client indicating that the lease has been released. This packet includes the Server Identifier and Lease Identifier options.
客户机将一个释放数据包单播到它从中分配地址的服务器。此数据包包括租约标识符选项。租约标识符与用于原始分配的标识符匹配。当服务器收到此数据包时，它取消客户机对该地址的租约，并向客户机发送一个ACK数据包，指示租约已解除。此数据包包括服务器标识符和租约标识符选项。
The following figure illustrates this exchange.
下图说明了此交换。
Client Server
v v
| |
|\_____________ |
| RELEASE \|
| |
| Cancels lease
| |
| _____________/|
|/ ACK |
| |
v v
Client Server
v v
| |
|\_____________ |
| RELEASE \|
| |
| Cancels lease
| |
| _____________/|
|/ ACK |
| |
v v
Figure 5: Timeline diagram of messages exchanged in Address Release example
图5：地址发布示例中交换的消息的时间线图
This is a continuation of the previous example. At some later time, the client decides to allocate another multicast address. Since it has recently worked with a server, it decides to try sending a unicast REQUEST to that server. If this doesn't work, it can always try a multicast DISCOVER, as illustrated in example 2.
这是上一个示例的延续。稍后，客户机决定分配另一个多播地址。由于它最近与服务器一起工作，它决定尝试向该服务器发送单播请求。如果这不起作用，它总是可以尝试多播发现，如示例2所示。
The client unicasts a REQUEST packet to the server from which it wants to allocate the address. This packet includes the Lease Time, Lease Identifier, and Multicast Scope options.
客户机将一个请求数据包单播到它想要从中分配地址的服务器。此数据包包括租约时间、租约标识符和多播作用域选项。
The server responds with an ACK packet containing the Lease Time, Lease Identifier, and Multicast Scope options from the REQUEST packet, as well as the Server Identifier option and a List of Address Ranges option listing the address allocated.
服务器响应ACK数据包，其中包含请求数据包中的租约时间、租约标识符和多播作用域选项，以及服务器标识符选项和列出分配地址的地址范围列表选项。
The client now has a lease on the multicast address.
客户端现在拥有多播地址的租约。
If the client had not received an ACK from the server, it would have retransmitted its REQUEST packet for a while. If it still received no response, it would start over with a multicast DISCOVER message.
如果客户端没有收到来自服务器的ACK，它将在一段时间内重新传输其请求数据包。如果仍然没有收到响应，它将使用多播发现消息重新开始。
The following figure illustrates this exchange.
下图说明了此交换。
Client Server
v v
| |
|\_____________ |
| REQUEST \|
| |
| Allocates address
| |
| _____________/|
|/ ACK |
| |
v v
Client Server
v v
| |
|\_____________ |
| REQUEST \|
| |
| Allocates address
| |
| _____________/|
|/ ACK |
| |
v v
Figure 6: Timeline diagram of messages exchanged in Unicast Address Allocation example
图6：单播地址分配示例中交换的消息的时间线图
APPENDIX B: Recommended Constant Values
附录B：推荐常量值
Table 6 lists recommended values for constants defined in this specification.
表6列出了本规范中定义的常数的建议值。
Constant Name Recommended Value
------------- -----------------
[CLOCK-SKEW-ALLOWANCE] 30 minutes
[DISCOVER-DELAY] current retransmit delay
[EXTRA-ALLOCATION-TIME] 1 hour
[NO-RESPONSE-DELAY] 60 seconds
[OFFER-HOLD] at least 60 seconds
[RESPONSE-CACHE-INTERVAL] at least 60 seconds (5 minutes maximum)
[XID-REUSE-INTERVAL] 10 minutes (required)
Constant Name Recommended Value
------------- -----------------
[CLOCK-SKEW-ALLOWANCE] 30 minutes
[DISCOVER-DELAY] current retransmit delay
[EXTRA-ALLOCATION-TIME] 1 hour
[NO-RESPONSE-DELAY] 60 seconds
[OFFER-HOLD] at least 60 seconds
[RESPONSE-CACHE-INTERVAL] at least 60 seconds (5 minutes maximum)
[XID-REUSE-INTERVAL] 10 minutes (required)
Table 6: Recommended Constant Values
表6：建议的恒定值
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。