rfc2730.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   The RELEASE message is used by a MADCAP client that wants to
   deallocate one or more multicast addresses before their lease
   expires.

   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.

   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.

   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.

2.3. Retransmission

   MADCAP clients are responsible for all message retransmission. The
   client MUST adopt a retransmission strategy that incorporates an
   exponential backoff algorithm to determine the delay between
   retransmissions. The delay between retransmissions SHOULD be chosen
   to allow sufficient time for replies from the server to be delivered
   based on the characteristics of the internetwork between the client
   and the server.

   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



Hanna, et al.               Standards Track                    [Page 17]

RFC 2730                         MADCAP                    December 1999


   message to another address.

   The client MAY provide an indication of retransmission attempts to
   the user as an indication of the progress of the process. The client
   MAY halt retransmission at any point.

2.4. The Lease Identifier

   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.

   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.

   New MADCAP Lease Identifier types may only be defined by IETF
   Consensus, as described in section 5.


           Lease Identifier Type   Name
           ---------------------   ----
                     0             Random Lease Identifier
                     1             Address-Specific Lease Identifier

      Table 3:  MADCAP Lease Identifier Types

   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.

   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.






Hanna, et al.               Standards Track                    [Page 18]

RFC 2730                         MADCAP                    December 1999


   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.

2.4.1. Random Lease Identifier

   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.

   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    |
   +---------+-------------...

2.4.2. Address-Specific Lease Identifier

   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).

   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.





Hanna, et al.               Standards Track                    [Page 19]

RFC 2730                         MADCAP                    December 1999


    Lease ID     Address Family      Address    Client-specific
      Type           Number                       Identifier
   +---------+---------+---------+-----...-----+-----...-----+
   |    1    |     addrfamily    |   address   | cli-spec id |
   +---------+---------+---------+-----...-----+-----...-----+

2.5. Associating Client and Server Messages

   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.

   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).

2.6. Processing Errors

   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.

   If a MADCAP client encounters an error while processing a message, it
   MUST ignore the message.





Hanna, et al.               Standards Track                    [Page 20]

RFC 2730                         MADCAP                    December 1999


2.7. Multicast Scopes

   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.

   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).

   If a MADCAP client is unable to determine its scope list using one of
   these techniques, it MAY temporarily assume a scope list consisting
   of a single scope. If it is using IPv4, it SHOULD use IPv4 Local
   Scope (239.255.0.0/16), with a maximum TTL of 16.  If it is using
   IPv6, it SHOULD use SCOP 3, with a maximum hop count of 16. Using
   this temporary scope list, it MAY attempt to contact a MADCAP server
   that can provide a scope list for it.

   When a MADCAP client requests an address with a DISCOVER or REQUEST
   message, it MUST specify the administrative scope from which the
   address should be allocated. This scope is indicated with the
   Multicast Scope option. Likewise, the server MUST include the
   Multicast Scope option in all OFFER messages and all ACK messages
   sent in response to REQUEST messages.

2.8. Multicast TTL

   Another way to limit propagation of multicast messages is by using
   TTL scoping. This technique has several disadvantages in comparison
   to administratively scoped multicast addresses (as described in [3]),
   but it is currently in widespread usage.

   With TTL scoping, areas of the network are designated as scopes.
   Routers on the edges of these areas are configured with TTL
   thresholds so that multicast packets are not forwarded unless their



Hanna, et al.               Standards Track                    [Page 21]

RFC 2730                         MADCAP                    December 1999


   remaining TTL exceeds this threshold. A packet which should be
   restricted to a given TTL scope should have an initial TTL less than
   that scope's TTL threshold. Similar techniques may be used with IPv6,
   using the Hop Count field instead of the TTL field.

   MADCAP may be used in an environment where administrative scoping is
   not in use and TTL scoping is. Under these circumstances, a MADCAP
   server MAY return a scope list that includes scopes with TTLs less
   than 255. The MADCAP client MAY then allocate addresses from these
   scopes, but MUST NOT set the TTL field of any packet sent to such an
   address to a value greater than the maximum TTL indicated in the
   scope list. In such an environment, it is recommended that the MADCAP
   Server Multicast Addresses associated with the IPv4 Local Scope (or
   SCOP 3 for IPv6) be configured using TTL thresholds so that packets
   sent to these addresses with TTL of 16 are not sent outside an
   appropriate boundary.  This will allow MADCAP clients to use their
   default behavior for finding MADCAP servers.

   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.