rfc2730.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,476 行 · 第 1/5 页

Network Working Group                                          S. Hanna
Requests for Comments: 2730                      Sun Microsystems, Inc.
Category: Standards Track                                      B. Patel
                                                            Intel Corp.
                                                                M. Shah
                                                        Microsoft Corp.
                                                          December 1999


     Multicast Address Dynamic Client Allocation Protocol (MADCAP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This document defines a protocol, Multicast Address Dynamic Client
   Allocation Protocol (MADCAP), that allows hosts to request multicast
   addresses from multicast address allocation servers.

1. Introduction

   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.

1.1. Terminology

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

   Constants used by this protocol are shown as [NAME-OF-CONSTANT], and
   summarized in Appendix B.




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


1.2. Definitions

   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 server or server
     A host providing multicast address allocation services via MADCAP.

   Multicast
     IP Multicast, as defined in [11] and modified in [12].

   Multicast Address
     An IP multicast address or group address, as defined in [11] and
     [13].  An identifier for a group of nodes.

   Multicast Scope
     A range of multicast addresses configured so that traffic sent to
     these addresses is limited to some subset of the internetwork. See
     [3] and [13].

   Scope ID
     The lowest numbered address in a multicast scope. This definition
     applies only within this document.

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




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


   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.

     This definition applies only within this document.

1.3. Motivation and Protocol Requirements

   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.









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


   Policy neutral: Allocation policies (such as who can allocate
   addresses) should not be dictated by the protocol.

   Conferencing support: When allocating an address for use in a
   conferencing environment, members of the conference should be able to
   modify a multicast address lease used for the conference.

1.4. Relationship with DHCP

   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.

1.5. Protocol Overview

   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.

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

   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.

   Messages sent by servers include the xid included in the original
   request so that clients can match up responses with requests.

   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



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


   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.

   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.

   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.

   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.

   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.

   For detailed descriptions of typical protocol exchanges, consult
   Appendix A.

   MADCAP is a mechanism rather than a policy. MADCAP allows local
   system administrators to exercise control over configuration
   parameters where desired. For example, MADCAP servers may be
   configured to limit the number of multicast addresses allocated to a
   single client. Properly enforcing such a limit requires cryptographic
   security, as described in the Security Consideration section.

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



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


2. Protocol Description

   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.

   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