[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Draft                                                  S. Hanna
draft-hanna-marp-00.txt                           Sun Microsystems, Inc.
SML Document #98-0046                                    30 January 1998
                                                   Expires: 30 July 1998

               Multicast Address Request Protocol (MARP)

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

   The Multicast Address Request Protocol (MARP) serves as a front end
   to the Multicast Address Allocation Architecture. Any host that
   wishes to allocate a multicast address may contact a Multicast
   Address Allocation Server and use MARP to request an address
   allocation for a specific interval, scope, etc. Later, the host may
   request an extension of the address allocation or deallocate the
   address if it is no longer needed.

1 Introduction

   Dynamically allocating multicast addresses on a global scale while
   providing high reliability, low probability of clashes, good
   utilization, and aggregation to reduce routing overhead is a
   complicated matter.  The Multicast Address Allocation Architecture
   [1] describes a multicast address allocation system that meets these
   requirements.

   The Multicast Address Request Protocol (MARP) serves as a front end
   to this multicast address allocation system. Any host that wishes to
   allocate a multicast address may contact a Multicast Address
   Allocation Server and use MARP to request an address allocation for a



Hanna                                                           [Page 1]


Internet Draft          draft-hanna-marp-00.txt             January 1998


   specific lifetime, scope, etc. Later, the host may request an
   extension of the address lifetime or deallocate the address if it is
   no longer needed.

   MARP plays the same role as MDHCP [2], but has certain advantages as
   described in section 5. Basically, it is simpler and more efficient
   because it doesn't have to maintain compatibility with DHCP.

   This document is an initial proposal intended to stimulate debate.
   There are still open issues, which are discussed in section 8.

1.1 Terminology

   MARP is used by an IP host that wants to allocate an IP multicast
   address from a pool of dynamically allocated addresses (or request
   other multicast address allocation services). The host requesting
   address allocation services is known as the "MARP client" or simply
   "client" and the host supplying these services is known as the "MARP
   server" or simply "server."

   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.

2 Protocol Overview

   All MARP packets are unicast UDP datagrams. There are three types of
   MARP packets: requests, responses, and ACKs. When a MARP client
   wishes to make a request, it sends a request packet to a MARP server.
   In the simplest and most common case, the server responds with a
   response packet and the client completes the exchange by sending an
   ACK packet. Thus, a typical MARP exchange consists of three packets:
   a request, a response, and an ACK. If packets are lost or a request
   takes a long time to process, more packets may be required.

   Requests and ACKs are sent to a reserved port on the server.  For
   now, port number 7342 should be used. If this document reaches RFC
   status, a port number will be assigned by the IANA.  Responses are
   sent to the port and IP address from which the corresponding request
   was received.

   All MARP packets have a common format, described in section 3. The
   packet type field is a single octet that marks the type of the
   packet.  While there are many possible values for this field (256, to
   be exact), they are divided into ranges that allow any MARP client or
   server to identify the packet and determine its appropriate behavior.

   The ranges of packet types are: Request, Response - Permanent Error,



Hanna                                                           [Page 2]


Internet Draft          draft-hanna-marp-00.txt             January 1998


   Response - Transient Error, Response - Success, Response - Progress
   Report, ACK, and Reserved. The next few sections describe these types
   and the appropriate behavior of a MARP client or server receiving a
   packet with this type. For more information about specific types, see
   section 4.

2.1 Requests

   A request packet is sent by the client when it wants to initiate a
   request. If no response is received for 10 seconds, the request
   packet MAY be retransmitted. See section 2.5 for more details on
   retransmitting requests.

   Each request includes a sequence number assigned by the client, which
   is included in each response or ACK that corresponds to that request
   so that they may be matched with the request. The client MUST NOT
   reuse a sequence number for at least 2 hours, as described in more
   detail in section 3.5.

   If a MARP server receives a request whose type it does not recognize
   or cannot process and does not expect to ever do so, it MUST send
   back a Cannot Process response (type 81, a Permanent Error). Servers
   MUST support at least the Allocate Multicast Address request.

   If a MARP client receives a request, it MUST ignore it.

2.2 Responses

   A response packet is sent by a server to a client that has sent a
   request.  There are four kinds of responses: Response - Permanent
   Error, Response - Transient Error, Response - Success, and Response -
   Progress Report. The first three are called terminal responses.

   There are generic and specific versions of each of these kinds. The
   specific versions convey extra information (such as the reason for an
   error or a multicast address for an Address Allocated response).

2.2.1 Sending Responses

   There are three reasons to send a response packet: when a request is
   completed (successfully or unsuccessfully), when a request is still
   ongoing and more than 3 seconds has passed since the request was
   received or the last response was sent (whichever is later), and when
   a retransmitted request is received.

   In the first case, a terminal response is sent. In the second case, a
   progress report is sent. In the third case, the last response sent
   (which may be terminal or not) is retransmitted.



Hanna                                                           [Page 3]


Internet Draft          draft-hanna-marp-00.txt             January 1998


   To reiterate, after a request is completed, a MARP server MUST send a
   terminal response to the client. After this, no more responses are
   sent for this request (unless a retransmitted request is received).

   If a request takes longer than 3 seconds to complete, the server MUST
   send a Progress Report Response. This informs the client that the
   request is still being processed. The Progress Report includes an
   estimate of when the request will complete. If the request takes
   longer than this estimate, the server MUST send another Progress
   Report and continue this process until the request has completed, at
   which time it MUST send a terminal response.

2.2.2 Handling Responses

   If a MARP client receives a Permanent Error Response, it should
   conclude that its request cannot be completed and this is a permanent
   condition.  The client MAY send the request to another MARP server.
   It SHOULD NOT send the same request to the same server again to see
   if the condition clears up.

   If a MARP client receives a Transient Error Response, it should
   conclude that its request cannot be completed, but this may be a
   transient condition.  The client MAY send the request to another MARP
   server or it MAY send the same request to the same server again to
   see if the condition clears up.  If it sends the same request to the
   same server, it SHOULD use an exponential backoff timer to avoid
   swamping the server with the same request.

   If a MARP client receives a Success Response, it should conclude that
   its request was completed successfully. Certain request types should
   result in only certain response types, which may include valuable
   data.  If such a request type was used and the response type is a
   Success Response, but not one of those expected, the client SHOULD
   behave as if a Permanent Error Response had been received.

   If a MARP client receives a Progress Report, it MUST reset its
   request retransmission timer to 10 seconds after the estimated
   completion time included in the Progress Report.

   If a MARP client receives a response whose specific type it does not
   recognize, it MUST treat it as the generic version of its type (e.g.
   an unrecognized type in the Response - Permanent Error range must be
   treated as a Generic Permanent Error packet). MARP clients MAY only
   recognize the generic responses.

   If a MARP server receives a response, it MUST ignore it.

2.3 ACKs



Hanna                                                           [Page 4]


Internet Draft          draft-hanna-marp-00.txt             January 1998


   A client MUST send an ACK packet when it receives a terminal response
   packet. This informs the server that the client has received a
   terminal response packet and the server MAY discard any state
   corresponding to this request (such as entries in its request cache).

   If a MARP server receives an ACK whose request sequence number it
   does not recognize, it MUST ignore it. If a MARP client receives an
   ACK, it MUST ignore it.

2.4 Reserved or Invalid Packets

   If a MARP client or server receives a packet with a type in the
   Reserved range or a packet that is otherwise invalid (too short, for
   instance), it MUST ignore it.

2.5 Retransmitting Requests

   To handle lost packets, the client SHOULD retransmit its request if
   no response is heard for an interval of 10 seconds (or 10 seconds
   after the estimated completion time included in a Progress Report).
   If no response is heard to a request retransmission, the client MAY
   retransmit its request up to 9 more times at 10 second intervals. At
   any point during this process, the client MAY (and after the tenth
   retransmission MUST) decide that the exchange has failed and send the
   request to another server or abort the request.

   The server MUST maintain a request cache (or equivalent) so that it
   can recognize retransmitted requests and resend the most recent
   response.  Items in this cache MUST be retained for at least 120
   seconds and no more than 2 hours after the terminal response is sent
   (unless an ACK for an item is received, in which case the item MAY be
   removed at that time).

   A retransmitted request packet MUST be exactly the same as the
   original.  The server MUST check the source IP address, port, and
   sequence number when recognizing retransmitted requests. When a
   signature is present, this MUST also be checked.

2.6 Finding a MARP Server

   Before it can send MARP requests, a MARP client must find a MARP
   server.  There are several ways that this can be done.

   1) The DNS host name or IP address of the MARP server MAY be
   statically configured or entered as a command line argument or via
   some other means.

   2) A DHCP server or some other dynamic configuration mechanism MAY be



Hanna                                                           [Page 5]


Internet Draft          draft-hanna-marp-00.txt             January 1998


   employed to find the IP address or DNS host name of the MARP server.

   3) The MARP client MAY monitor Address Allocation Protocol (AAP) [3]
   messages on the multicast address used by AAP servers within the
   scope zone from which an address is to be allocated and choose one of
   the servers that are sending ADDRESS-IN-USE messages.

   The third technique is preferred. If this method is used, the MARP
   client SHOULD choose randomly among the AAP servers heard from.  This
   helps to avoid overloading the AAP servers.

2.7 Discovering Scopes

   The set of scope zones in use may be statically configured or
   discovered by monitoring MZAP [4] transmissions. Dynamic discovery is
   more robust, but takes time.

   A scope discovery message could be added to MARP, but it is important
   to be sure the MARP server has the same set of scopes as the MARP
   client and this is difficult to do without knowing what the scope
   zones are (circular problem) or statically configuring the MARP
   server address in the client (painful).

2.8 MARP Times

   MARP packets contain a number of places where absolute times must be
   represented. These time values are represented as unsigned 32-bit
   integers in network byte order giving the number of seconds since
   00:00 UTC, 1st January 1970. This is the same time value that is used
   in the Address Allocation Protocol [3].

   Two special time values are defined. A time value of 0 (also known as
   TIME_ASAP) means as early as possible. A time value of 2^32 - 1 (all
   ones, also known as TIME_ALAP) means as late as possible. These
   values are only allowed where explicitly stated.

   If the clocks on the MARP client and MARP server are set differently,
   problems can occur (like clients using addresses at the wrong time).
   To prevent substantial clock skew, the MARP client includes its idea
   of the current time in each Allocate Multicast Address request. If
   this differs from the server's current time when the request is
   received by more than 90 minutes, the server sends back a Clock Skew
   Permanent Error.

   To avoid problems caused by clock skew of less than 90 minutes (and
   network delays), the MARP client SHOULD allocate addresses for at
   least 2 hours earlier and 2 hours later than will be needed and let
   the address sit idle for these hours. This will take care of two



Hanna                                                           [Page 6]


Internet Draft          draft-hanna-marp-00.txt             January 1998


   clients that have almost 90 minutes of clock skew from the server in
   opposite directions and one hour of network delays, multicast routing
   latency, etc.

3 Generic Packet Format

   All MARP packets are unicast UDP datagrams. Requests and ACKs are
   sent to a reserved port on the server. Responses are sent to the port
   and IP address from which the corresponding request was received.

   All MARP packets share a common format, shown in Figure 1 (omitting
   UDP headers).

                          0 1 2 3 4 5 6 7
                         +-+-+-+-+-+-+-+-+
                         |Version| Flags |
                         +-+-+-+-+-+-+-+-+
                         |Sec. Hdr. (opt)|
                         +-+-+-+-+-+-+-+-+
                         |     Type      |
                         +-+-+-+-+-+-+-+-+
                         |    Request    |
                         | Sequence Num. |
                         +-+-+-+-+-+-+-+-+
                         |  Data Length  |
                         |      (N)      |
                         +-+-+-+-+-+-+-+-+
                         |               |
                         +     Data      +
                                ...
                         +   (N bytes)   +
                         |               |
                         +-+-+-+-+-+-+-+-+

                             Figure 1

3.1 Version (4 bits)

   The Version field is always 0 for this version of MARP.  If another
   value is seen, the packet MUST be ignored.  MARP should be extensible
   enough so that the version need never be changed. New request and
   response types may be added easily and handled properly by older
   clients and servers that don't recognize them.

3.2 Flags (4 bits)

   The most significant bit of the Flags field (marked 4 above) is the
   Security bit (described in section 3.3, Security Header). The three



Hanna                                                           [Page 7]


Internet Draft          draft-hanna-marp-00.txt             January 1998


   least significant bits MUST be sent as zero (0) and ignored on
   reception.  This allows for future extensions of the protocol in a
   backward compatible fashion.

3.3 Security Header (variable length)

   If the Security bit in the Flags field is set to 1, a Security Header
   appears after the Flags field. The format of the Security Header is
   shown in Figure 2.

                          0 1 2 3 4 5 6 7
                         +-+-+-+-+-+-+-+-+
                         |   Sig. Type   |
                         +-+-+-+-+-+-+-+-+
                         |  Sig. Length  |
                         |     (SL)      |
                         +-+-+-+-+-+-+-+-+
                         |               |
                         +   Sig. Data   +
                                ...
                         +   (SL bytes)  +
                         |               |
                         +-+-+-+-+-+-+-+-+
                         |   Encr. Type  |
                         +-+-+-+-+-+-+-+-+
                         | Encr. Length  |
                         |     (EL)      |
                         +-+-+-+-+-+-+-+-+
                         |               |
                         +  Encr. Data   +
                                ...
                         +   (EL bytes)  +
                         |               |
                         +-+-+-+-+-+-+-+-+

                             Figure 2

3.3.1 Signature

   If the Signature Type field is zero, no digital signature is included
   in this packet. The Signature Length field must be zero and the
   Signature Data field must be omitted.

   Otherwise, the Signature Type field identifies the type of digital
   signature used. The Signature Data field includes the digital
   signature of all bytes in the packet after the Signature Data field.
   The Signature Length field includes the number of bytes of data in
   the Signature Data field.



Hanna                                                           [Page 8]


Internet Draft          draft-hanna-marp-00.txt             January 1998


   If a MARP server receives a packet whose Signature Type field it does
   not support, it MUST send back a Signature Type Not Supported
   Permanent Error packet. If it supports the Signature Type but cannot
   verify the signature, it SHOULD send back a Signature Not Verified
   Permanent Error packet.  However, if the packet also uses encryption
   and cannot be decrypted, the decryption errors described in section
   3.3.2 MUST be sent instead.

   If a MARP server receives a request whose Signature Type field it
   supports, it SHOULD use the same Signature Type in its response since
   the MARP client clearly supports this Signature Type.

   If a MARP client receives a packet whose signature it cannot verify,
   it SHOULD ignore it.

   MARP servers and clients MAY be configured to support any set of
   signature types, based on administrative decisions.

3.3.1.1 DSA Signature

A packet whose Signature Type is 1 is signed with DSA (Digital Signature
Standard). The Signature Data field contains the name associated with
the private key used to sign the data and the signature itself. No
certificates are included with this type of signature. The recipient is
expected to have access to a public key infrastructure or other
mechanism for finding and verifying the public key associated with a
name.

3.3.2 Encryption

If the Encryption Type field is zero, encryption is not used on this
packet.  The Encryption Length field must be zero and the Encryption
Data field must be omitted.

Otherwise, the Encryption Type field identifies the type of encryption
used.  The Encryption Data field includes data which is specific to the
encryption method used. The Encryption Length field includes the number
of bytes of data in the Encryption Data field. All bytes in the packet
after the Encryption Data field are ciphertext (including the Type and
Request Sequence Number).

If a MARP server receives a packet whose Encryption Type field it does
not support, it MUST send back a Encryption Type Not Supported Permanent
Error packet. Since it cannot decrypt the packet, it cannot read its
Type or Request Sequence Number fields. It MUST use sequence number 0 in
its response and MUST NOT cache this response.

If a MARP server receives a packet whose Encryption Type field it



Hanna                                                           [Page 9]


Internet Draft          draft-hanna-marp-00.txt             January 1998


supports but which it cannot decrypt, it MUST send back a Decryption
Failed Permanent Error packet. Since it cannot decrypt the packet, it
cannot read its type or request sequence number. It MUST use sequence
number 0 in its response and MUST NOT cache this response.

If a MARP server receives a request whose Encryption Type field it
supports, it SHOULD use the same Encryption Type in its response since
the MARP client clearly supports this Encryption Type.

If a MARP client receives a packet whose Encryption Type field it does
not support or which it cannot decrypt, it MUST ignore the packet.

MARP servers and clients MAY be configured to support any set of
encryption types, based on administrative decisions.

3.3.2.1 Triple DES Encryption

A packet whose Encryption Type is 1 is encrypted with Triple DES (DES-
EDE as per spec - 168 bit key derived from 192) using a key that is
randomly selected by the MARP client on a per-request basis (called the
request key). For requests, the request key is encrypted with the public
key of the MARP server and included in the Encryption Data field. For
responses and ACKs, the same key is used, but it is not transmitted in
the response or ACK packet.

Cipher Block Chaining (CBC) is used with a 64 bit (8 byte)
initialization vector (IV) chosen randomly by the client and included in
the Encryption Data field. The same IV is used in a response or ACK, but
not transmitted in the response or ACK packet.

Because DES-3EDE-CBC requires the length of the plaintext to be a
multiple of 64 bits (8 bytes), padding is added to the plaintext as
necessary until it reaches such a length. The number of pad bytes added
is included in the Encryption Data field so that they may be stripped
off after decryption.  The pad bytes have values 1, 2, 3, and so forth
(up to a maximum of 7) until the plaintext reaches a multiple of 8
bytes.

In a request packet, the Encryption Data field contains the request key
(encrypted with the public key of the server) followed by the name that
is associated with the server's public key (preceded by a length byte),
the IV, and a single byte with the number of pad bytes. In a response or
ACK packet, the Encryption Data field contains the number of pad bytes
and the Encryption Length field is 1.

3.4 Type (1 byte)

The Type field indicates what type of MARP packet this is. There are



Hanna                                                          [Page 10]


Internet Draft          draft-hanna-marp-00.txt             January 1998


several ranges of type values so that more types may be defined in the
future and older implementations will be able to respond in a well-
defined manner.  These ranges are listed in Figure 3 and described in
more detail in sections 2 and 4.

          Type Range      Meaning
          ----------      -------
            00 - 3f       Request
            40 - 7f       Response - Success
            80 - 9f       Response - Permanent Error
            a0 - bf       Response - Transient Error
            c0 - df       Response - Progress Report
            e0            ACK
            e1 - ff       Reserved

              Figure 3

3.5 Request Sequence Number (2 bytes)

   The request sequence number is a 2 octet number chosen by the MARP
   client and sent in the initial request packet. The same sequence
   number is included in each response, ACK, or retransmitted request
   that corresponds to the initial request.

   The sequence number 0 MUST NOT be sent in a request, since the MARP
   server uses this value for responding to encrypted packets that it
   could not decrypt and whose sequence number it therefore could not
   read.

   It is undesirable to have the same sequence number used for two
   different requests from the same source IP address and port within a
   few hours, as packets from the old request may be hanging around the
   network or (within a few minutes) the server's request cache.

   Therefore, a MARP client MUST NOT reuse a request sequence number
   with the same source IP address and port within 2 hours of the
   initial request.  Also, a MARP client SHOULD choose its request
   sequence numbers in such a way that it is unlikely that another MARP
   client with the same source IP address and port used the same
   sequence number within the past 2 hours.

   One simple way to do this is to choose the initial sequence number
   randomly, then increment it for subsequent requests from the same
   client. As long as the client is not sending more than 32,768
   requests per hour there will be no problem.

3.6 Data Length and Data




Hanna                                                          [Page 11]


Internet Draft          draft-hanna-marp-00.txt             January 1998


   The Data Length field is an unsigned two octet number in network byte
   order that specifies how many bytes of data are included in the
   packet.  This field is followed by the specified number of bytes of
   data. The meaning of the data depends on the packet type.

4 Specific Packet Types

   This section describes the meaning of specific values of the Type
   field in a MARP packet.

4.1 Requests

4.1.1 Allocate Multicast Address (type 00)

   The Allocate Multicast Address request asks the MARP server to
   allocate a multicast address. If the request succeeds, a Multicast
   Address Allocation Success response MUST be returned.  If the request
   fails because no addresses are available that would satisfy the
   request, the No Addresses Available Transient Error response SHOULD
   be returned.

   The Data Length varies depending on the address type. The format of
   the data is shown in Figure 4.

   If an Allocate Multicast Address request is signed, the MARP server
   SHOULD remember the identity that signed it so that it may use this
   information to control who may deallocate the address or change its
   interval.

   To avoid malicious users allocating all the addresses on a MARP
   server, several techniques may be employed. The MARP server MAY limit
   the number of addresses that may be allocated in an hour. It MAY
   limit address allocation based on identity (as verified by
   signature). Both of these are good techniques.

   If a MARP server limits address allocation based on identity, it
   SHOULD cache requests for at least two hours to avoid replay attacks
   (replaying an authorized allocation request to use up someone's
   allocation).












Hanna                                                          [Page 12]


Internet Draft          draft-hanna-marp-00.txt             January 1998


                          0 1 2 3 4 5 6 7
                         +-+-+-+-+-+-+-+-+
                         | Address Type  |
                         +-+-+-+-+-+-+-+-+
                         | Address Count |
                         +-+-+-+-+-+-+-+-+
                         |               |
                         +     Scope     +
                                ...
                         + (size varies  +
                         |with addr type)|
                         +-+-+-+-+-+-+-+-+
                         |    Current    |
                         |     Time      |
                         |               |
                         |               |
                         +-+-+-+-+-+-+-+-+
                         |   Requested   |
                         |    Address    |
                         |     Start     |
                         |     Time      |
                         +-+-+-+-+-+-+-+-+
                         |   Requested   |
                         |    Address    |
                         |     End       |
                         |     Time      |
                         +-+-+-+-+-+-+-+-+
                         |   Required    |
                         |    Address    |
                         |     Start     |
                         |     Time      |
                         +-+-+-+-+-+-+-+-+
                         |   Required    |
                         |    Address    |
                         |     End       |
                         |     Time      |
                         +-+-+-+-+-+-+-+-+

                             Figure 4

4.1.1.1 Address Type (1 byte)

   The Address Type field indicates the type of addresses being
   requested.  It is 0 for IPv4 multicast addresses and 1 for IPv6
   multicast addresses.  All other values are reserved. Clients MUST not
   send them and servers MUST ignore requests that contain them.

4.1.1.2 Address Count (1 byte)



Hanna                                                          [Page 13]


Internet Draft          draft-hanna-marp-00.txt             January 1998


   The Address Count field indicates the number of addresses being
   requested.  It may have any value from 1 to 255. The value 0 is
   reserved. Clients MUST not send it and servers MUST ignore requests
   that contain it.

4.1.1.3 Scope (variable length)

   The Scope field is the first IP address in the scope zone from which
   the address must be allocated. The length of the Scope field is 4 if
   the Address Type field is 0 and 16 if the Address Type field is 1.

   If the Scope field is all 0s, global scope is implied.  The MARP
   server and client must both be in the scope zone requested.  This is
   guaranteed if the client uses AAP to find MARP servers.

4.1.1.4 Current Time (4 bytes)

   The Current Time is the client's idea of the current time when the
   request was first made. This value does not change when a request is
   retransmitted, so it may be a few minutes old when received by the
   server.  Neither 0 (TIME_ASAP) nor 2^32 - 1 (TIME_ALAP) are valid
   here.

   If a MARP server receives an Allocate Multicast Address request that
   includes a current time that differs from its own by more than 90
   minutes, it MUST return a Clock Skew Permanent Error response. This
   avoids misunderstandings caused by substantial clock skew. If a MARP
   server caches requests for two hours, this will also prevent replay
   attacks.

4.1.1.5 Requested Address Start Time (4 bytes)

   The Requested Address Start Time is the time at which the client
   would like the allocation to start. This is a MARP time, as described
   in section 2.7. A time value of 0 (TIME_ASAP) is valid here, but 2^32
   - 1 (TIME_ALAP) is not.

4.1.1.6 Requested Address End Time (4 bytes)

   The Requested Address End Time is the time at which the client would
   like the allocation to end. This is a MARP time, as described in
   section 2.7. This value MUST be greater than the requested address
   start time.  A time value of 2^32 - 1 (TIME_ALAP) is valid here, but
   0 (TIME_ASAP) is not.

4.1.1.7 Required Address Start Time (4 bytes)

   The Required Address Start Time is the latest time that the client is



Hanna                                                          [Page 14]


Internet Draft          draft-hanna-marp-00.txt             January 1998


   willing to accept as an address start time. If the server cannot
   supply an address whose start time is at least this early, it MUST
   send a failure response. This is a MARP time, as described in section
   2.7. A time value of 0 (TIME_ASAP) is valid here, but 2^32 - 1
   (TIME_ALAP) is not. TIME_ASAP here means that only a time value of
   TIME_ASAP may be returned.

4.1.1.8 Required Address End Time (4 bytes)

   The Required Address End Time is the earliest time that the client is
   willing to accept as an address end time. If the server cannot supply
   an address whose end time is at least this late, it MUST send a
   failure response. This is a MARP time, as described in section 2.7.
   This value MUST be greater than the required address start time.
   Neither 0 (TIME_ASAP) nor 2^32 - 1 (TIME_ALAP) are valid here.

4.1.2 Deallocate Multicast Address (type 01)

   The Deallocate Multicast Address request asks the MARP server to
   deallocate a multicast address. If the request succeeds, a Generic
   Success response MUST be returned.

   The Data Length varies depending on the address type. The format of
   the data is shown in Figure 5.

   It is strongly suggested that MARP servers require Deallocate
   Multicast Address requests to be signed and make sure that they are
   signed by an identity with permission to deallocate the address (such
   as the same identity that allocated the address). Otherwise,
   malicious users may change the interval of addresses allocated by
   others.




















Hanna                                                          [Page 15]


Internet Draft          draft-hanna-marp-00.txt             January 1998


                          0 1 2 3 4 5 6 7
                         +-+-+-+-+-+-+-+-+
                         | Address Type  |
                         +-+-+-+-+-+-+-+-+
                         |   Allocated   |
                         +    Address    +
                                ...
                         + (size varies  +
                         |with addr type)|
                         +-+-+-+-+-+-+-+-+
                         |    Address    |
                         |     Start     |
                         |     Time      |
                         |               |
                         +-+-+-+-+-+-+-+-+
                         |    Address    |
                         |     End       |
                         |     Time      |
                         |               |
                         +-+-+-+-+-+-+-+-+

                             Figure 5

4.1.2.1 Address Type (1 byte)

   The Address Type field indicates the type of address being
   deallocated.  It is 0 for IPv4 multicast addresses and 1 for IPv6
   multicast addresses.  All other values are reserved. Clients MUST not
   send them and servers MUST ignore requests that contain them.

4.1.2.2 Allocated Address (variable length)

   The Allocated Address field is the address being deallocated.  The
   length of the Allocated Address field is 4 if the Address Type field
   is 0 and 16 if the Address Type field is 1.

4.1.2.2 Address Start Time (4 bytes)

   The Address Start Time is the address start time for this address.
   It MUST match the value included in the most recent Multicast Address
   Allocation Success Response or Change Address Interval Success
   Response sent by the server for this address. A MARP server MAY omit
   checking this value if it does not allocate a given address more than
   once for different intervals. The time value 0 (TIME_ASAP) is valid
   here, but 2^32 - 1 (TIME_ALAP) is not.

4.1.2.3 Address End Time (4 bytes)




Hanna                                                          [Page 16]


Internet Draft          draft-hanna-marp-00.txt             January 1998


   The Address End Time is the address end time for this address.  It
   MUST match the value included in the most recent Multicast Address
   Allocation Success Response or Change Address Interval Success
   Response sent by the server for this address. A MARP server MAY omit
   checking this value if it does not allocate a given address more than
   once for different intervals. Neither 0 (TIME_ASAP) nor 2^32 - 1
   (TIME_ALAP) is valid here.

4.1.3 Change Interval (type 02)

   The Change Interval request asks the MARP server to change the start
   and end time of a multicast address that has already been allocated
   with this MARP server. If the request succeeds, a Change Interval
   Success response MUST be returned. If the request fails, the address
   remains allocated with the old interval.

   It is strongly suggested that MARP servers require Change Interval
   requests to be signed and make sure that they are signed by an
   identity with permission to change the interval of the address (such
   as the same identity that allocated the address).  Otherwise,
   malicious users may change the interval of addresses allocated by
   others.

   The Data Length varies depending on the address type. The format of
   the data is shown in Figure 6.


























Hanna                                                          [Page 17]


Internet Draft          draft-hanna-marp-00.txt             January 1998


                          0 1 2 3 4 5 6 7
                         +-+-+-+-+-+-+-+-+
                         | Address Type  |
                         +-+-+-+-+-+-+-+-+
                         |   Allocated   |
                         +    Address    +
                                ...
                         + (size varies  +
                         |with addr type)|
                         +-+-+-+-+-+-+-+-+
                         |    Address    |
                         |     Start     |
                         |     Time      |
                         |               |
                         +-+-+-+-+-+-+-+-+
                         |    Address    |
                         |     End       |
                         |     Time      |
                         |               |
                         +-+-+-+-+-+-+-+-+
                         |   Requested   |
                         |    Address    |
                         |     Start     |
                         |     Time      |
                         +-+-+-+-+-+-+-+-+
                         |   Requested   |
                         |    Address    |
                         |     End       |
                         |     Time      |
                         +-+-+-+-+-+-+-+-+
                         |   Required    |
                         |    Address    |
                         |     Start     |
                         |     Time      |
                         +-+-+-+-+-+-+-+-+
                         |   Required    |
                         |    Address    |
                         |     End       |
                         |     Time      |
                         +-+-+-+-+-+-+-+-+

                             Figure 6

4.1.3.1 Address Type (1 byte)

   The Address Type field indicates the type of address whose interval
   is to be changed.  It is 0 for IPv4 multicast addresses and 1 for
   IPv6 multicast addresses.  All other values are reserved. Clients



Hanna                                                          [Page 18]


Internet Draft          draft-hanna-marp-00.txt             January 1998


   MUST not send them and servers MUST ignore requests that contain
   them.

4.1.3.2 Allocated Address (variable length)

   The Allocated Address field is the address whose interval is to be
   changed.  The length of the Allocated Address field is 4 if the
   Address Type field is 0 and 16 if the Address Type field is 1.

4.1.3.3 Address Start Time (4 bytes)

   The Address Start Time is the address start time for this address.
   It MUST match the value included in the most recent Multicast Address
   Allocation Success Response or Change Address Interval Success
   Response sent by the server for this address. A MARP server MAY omit
   checking this value if it does not allocate a given address more than
   once for different intervals. The time value 0 (TIME_ASAP) is valid
   here, but 2^32 - 1 (TIME_ALAP) is not.

4.1.3.4 Address End Time (4 bytes)

   The Address End Time is the address end time for this address.  It
   MUST match the value included in the most recent Multicast Address
   Allocation Success Response or Change Address Interval Success
   Response sent by the server for this address. A MARP server MAY omit
   checking this value if it does not allocate a given address more than
   once for different intervals. Neither 0 (TIME_ASAP) nor 2^32 - 1
   (TIME_ALAP) is valid here.

4.1.3.5 Requested Address Start Time (4 bytes)

   The Requested Address Start Time is the time at which the client
   would like to start using the address. This is a MARP time, as
   described in section 2.7. A time value of 0 (TIME_ASAP) is valid
   here, but 2^32 - 1 (TIME_ALAP) is not.

4.1.3.6 Requested Address End Time (4 bytes)

   The Requested Address End Time is the time at which the client would
   like to stop using the address. This is a MARP time, as described in
   section 2.7. This value MUST be greater than the requested address
   start time.  A time value of 2^32 - 1 (TIME_ALAP) is valid here, but
   0 (TIME_ASAP) is not.

4.1.3.7 Required Address Start Time (4 bytes)

   The Required Address Start Time is the latest time that the client is
   willing to accept as an address start time. If the server cannot



Hanna                                                          [Page 19]


Internet Draft          draft-hanna-marp-00.txt             January 1998


   supply an address whose start time is at least this early, it MUST
   send a failure response. However, the address MUST remain allocated
   with the old interval. This is a MARP time, as described in section
   2.7. A time value of 0 (TIME_ASAP) is valid here, but 2^32 - 1
   (TIME_ALAP) is not. TIME_ASAP here means that only a time value of
   TIME_ASAP may be returned.

4.1.3.8 Required Address End Time (4 bytes)

   The Required Address End Time is the earliest time that the client is
   willing to accept as an address end time. If the server cannot supply
   an address whose end time is at least this late, it MUST send a
   failure response. However, the address MUST remain allocated with the
   old interval. This is a MARP time, as described in section 2.7. This
   value MUST be greater than the required address start time.  Neither
   0 (TIME_ASAP) nor 2^32 - 1 (TIME_ALAP) are valid here.

4.2 Responses

   This section describes the meaning of specific responses. For a
   description of how to handle responses in general, see section 2.2.2.

4.2.1 Generic Success (type 40)

   The Generic Success response indicates that a request completed
   successfully. No data is included.

4.2.2 Multicast Address Allocation Success (type 41)

   The Multicast Address Allocation Success response indicates that an
   Allocate Multicast Address request completed successfully. The data
   contains the addresses allocated and the interval during which they
   are allocated.

   The Data Length varies depending on the address type (given in the
   request). The format of the data is shown in Figure 7.

   The MARP server does not have to return the number of addresses
   requested.  It MAY return any number of addresses from 1 to the
   number requested in a Multicast Address Allocation Success Response.
   However, it MUST NOT return more addresses than requested.

   The addresses returned do not have to be contiguous, although they
   may be.  There is no way for a MARP client to request contiguous
   addresses or to request that a specific multicast address be
   allocated. MARP clients SHOULD NOT assume or attempt to achieve such
   conditions.




Hanna                                                          [Page 20]


Internet Draft          draft-hanna-marp-00.txt             January 1998


                          0 1 2 3 4 5 6 7
                         +-+-+-+-+-+-+-+-+
                         |    Address    |
                         |     Start     |
                         |     Time      |
                         |               |
                         +-+-+-+-+-+-+-+-+
                         |    Address    |
                         |     End       |
                         |     Time      |
                         |               |
                         +-+-+-+-+-+-+-+-+
                         | Address Count |
                         +-+-+-+-+-+-+-+-+
                         |   Allocated   |
                         +   Addresses   +
                                ...
                         + (size varies  +
                         |with addr type)|
                         +-+-+-+-+-+-+-+-+

                             Figure 7

4.2.2.1 Address Start Time (4 bytes)

   The Address Start Time is the time at which the client MAY start
   using the allocated addresses. This is a MARP time, as described in
   section 2.7. A time value of 0 (TIME_ASAP) is valid here, but 2^32 -
   1 (TIME_ALAP) is not. TIME_ASAP means that the addresses may be used
   immediately. The MARP server SHOULD return TIME_ASAP instead of the
   current time, as this value removes any confusion caused by clock
   skew.

4.2.2.2 Address End Time (4 bytes)

   The Address End Time is the time at which the client MUST stop using
   the allocated addresses. This is a MARP time, as described in section
   2.7. Neither 0 (TIME_ASAP) nor 2^32 - 1 (TIME_ALAP) is valid here.

4.2.2.3 Address Count (1 byte)

   The Address Count is the number of addresses that the MARP server has
   allocated.

4.2.2.4 Allocated Addresses (variable length)

   The Allocated Addresses field contains the addresses that have been
   allocated. The length of each address is 4 if the address type



Hanna                                                          [Page 21]


Internet Draft          draft-hanna-marp-00.txt             January 1998


   specified in the request is 0 (IPv4 addresses) and 16 if the address
   type is 1 (IPv6 addresses).

4.2.3 Change Interval Success (type 42)

   The Change Interval Success response indicates that a Change Interval
   request completed successfully. The data contains the new interval
   during which the address is allocated.

   The Data Length is always 8. The format of the data is shown in
   Figure 8.

                          0 1 2 3 4 5 6 7
                         +-+-+-+-+-+-+-+-+
                         |    Address    |
                         |     Start     |
                         |     Time      |
                         |               |
                         +-+-+-+-+-+-+-+-+
                         |    Address    |
                         |     End       |
                         |     Time      |
                         |               |
                         +-+-+-+-+-+-+-+-+

                             Figure 8

4.2.3.1 Address Start Time (4 bytes)

   The Address Start Time is the time at which the client may start
   using the allocated address. This is a MARP time, as described in
   section 2.7. A time value of 0 (TIME_ASAP) is valid here, but 2^32 -
   1 (TIME_ALAP) is not. TIME_ASAP means that the address may be used
   immediately. The MARP server SHOULD return TIME_ASAP instead of the
   current time, as this value removes any confusion caused by clock
   skew.

4.2.3.2 Address End Time (4 bytes)

   The Address End Time is the time at which the client may stop using
   the allocated address. This is a MARP time, as described in section
   2.7. Neither 0 (TIME_ASAP) nor 2^32 - 1 (TIME_ALAP) is valid here.

4.2.4 Generic Permanent Error (type 80)

   The Generic Permanent Error response indicates that a request cannot
   be completed and this is a permanent condition. No data is included.
   For a description of how to handle this response, see section 2.2.2.



Hanna                                                          [Page 22]


Internet Draft          draft-hanna-marp-00.txt             January 1998


4.2.5 Cannot Process Permanent Error (type 81)

   The Cannot Process Permanent Error response indicates that a request
   cannot be processed because it is unrecognized or unsupported and
   this is a permanent condition.  No data is included. For a
   description of how to handle this response, see section 2.2.2.

4.2.6 Encryption Type Not Supported Permanent Error (type 82)

   The Encryption Type Not Supported Permanent Error response indicates
   that a packet cannot be processed because the MARP server does not
   support the value in the Encryption Type field. Since the MARP server
   cannot decrypt the packet, it cannot read its Type or Request
   Sequence Number fields. It MUST use sequence number 0 in its response
   and MUST NOT cache this response.

   The data contains a list of supported encryption types and as much of
   the original packet as will fit in a single UDP packet.  The MARP
   client MAY decrypt this packet to recognize which request failed and
   try sending it again with a different encryption type.

   The format of the data is shown in Figure 9.

                          0 1 2 3 4 5 6 7
                         +-+-+-+-+-+-+-+-+
                         | E. Type Count |
                         +-+-+-+-+-+-+-+-+
                         |  Sptd. Enc.   |
                         +    Types      +
                                ...
                         +  (ETC bytes)  +
                         |               |
                         +-+-+-+-+-+-+-+-+
                         | Pkt Data Len  |
                         |     (PDL)     |
                         +-+-+-+-+-+-+-+-+
                         |    Packet     |
                         +     Data      +
                                ...
                         +  (PDL bytes)  +
                         |               |
                         +-+-+-+-+-+-+-+-+

                             Figure 9

4.2.6.1 Encryption Type Count (1 byte)

   The Encryption Type Count field is a one octet unsigned number



Hanna                                                          [Page 23]


Internet Draft          draft-hanna-marp-00.txt             January 1998


   indicating how many supported encryption types are included in the
   Supported Encryption Types field. Since each entry in this list is 1
   byte long, this value is also the length of that field in bytes.

4.2.6.2 Supported Encryption Types (variable length)

   The Supported Encryption Types field is a series of one octet numbers
   indicating which encryption types are supported by the MARP server.
   These numbers need not be sorted in any way, although they should not
   include duplicates.

4.2.6.3 Packet Data Length (2 bytes)

   The Packet Data Length field is a two octet unsigned number giving
   the length of the following Packet Data field in bytes.

4.2.6.4 Packet Data (variable length)

   The Packet Data field contains as much of the packet that could not
   be decrypted as will fit into the response. This data starts with the
   Version field, thus skipping the UDP header of the original packet.

4.2.7 Decryption Failed Permanent Error (type 83)

   The Decryption Failed Permanent Error response indicates that a
   packet cannot be processed because the MARP server supports the value
   in the Encryption Type field but was unable to decrypt the packet.
   Since the MARP server cannot decrypt the packet, it cannot read its
   Type or Request Sequence Number fields. It MUST use sequence number 0
   in its response and MUST NOT cache this response.

   The data contains the complete contents of the original packet
   (although the end of the packet may need to be clipped in order to
   fit in a single UDP packet). The MARP client MAY verify that it sent
   this packet and decrypt it to recognize which request failed and what
   the problem was.

4.2.8 Signature Type Not Supported Permanent Error (type 84)

   The Signature Type Not Supported Permanent Error response indicates
   that a packet cannot be processed because the MARP server does not
   support the value in the Signature Type field. No data is included.
   For a description of how to handle this response, see section 2.2.2.

   The data contains a list of supported signature types. The format of
   the data is shown in Figure 10.





Hanna                                                          [Page 24]


Internet Draft          draft-hanna-marp-00.txt             January 1998


                          0 1 2 3 4 5 6 7
                         +-+-+-+-+-+-+-+-+
                         | S. Type Count |
                         +-+-+-+-+-+-+-+-+
                         |  Sptd. Sig.   |
                         +    Types      +
                                ...
                         +  (STC bytes)  +
                         |               |
                         +-+-+-+-+-+-+-+-+

                             Figure 10

4.2.8.1 Signature Type Count (1 byte)

   The Signature Type Count field is a one octet unsigned number
   indicating how many supported signature types are included in the
   Supported Signature Types field. Since each entry in this list is 1
   byte long, this value is also the length of that field in bytes.

4.2.8.2 Supported Signature Types (variable length)

   The Supported Signature Types field is a series of one octet numbers
   indicating which signature types are supported by the MARP server.
   These numbers need not be sorted in any way, although they should not
   include duplicates.

4.2.9 Signature Not Verified Permanent Error (type 85)

   The Signature Not Verified Permanent Error response indicates that a
   packet cannot be processed because the MARP server supports the value
   in the Signature Type field, but could not verify the signature.  No
   data is included. For a description of how to handle this response,
   see section 2.2.2.

4.2.10 Clock Skew Permanent Error (type 86)

   The Clock Skew Permanent Error response indicates that the current
   time supplied by the client differs from that maintained by the
   server by more than 90 minutes. The current time included in the
   packet and the server's idea of the current time are included in the
   data.

   It is suggested that the MARP client log an error noting these values
   along with the server identity or IP address.  It is not suggested
   that the MARP client adjust its clock automatically, since the server
   clock may in fact be in error.  In any case, the client SHOULD NOT
   send any more requests to this server until the clock skew problem is



Hanna                                                          [Page 25]


Internet Draft          draft-hanna-marp-00.txt             January 1998


   addressed.

   The Data Length is always 8. The format of the data is shown in
   Figure 11.

                          0 1 2 3 4 5 6 7
                         +-+-+-+-+-+-+-+-+
                         |    Client     |
                         |    Current    |
                         |     Time      |
                         |               |
                         +-+-+-+-+-+-+-+-+
                         |    Server     |
                         |    Current    |
                         |     Time      |
                         |               |
                         +-+-+-+-+-+-+-+-+

                             Figure 11

4.2.11 Generic Transient Error (type a0)

   The Generic Transient Error response indicates that a request cannot
   be completed, but this may be a transient condition. No data is
   included. For a description of how to handle this response, see
   section 2.2.2.

4.2.12 No Addresses Available Transient Error (type a1)

   The No Addresses Available Transient Error response indicates that no
   addresses were available that would satisfy a request. This response
   is sent if no addresses are available that satisfy an Allocate
   Multicast Address request, for instance.  No data is included. For a
   description of how to handle this response, see section 2.2.2.

4.2.13 Generic Progress Report (type c0)

   The Generic Success response indicates that a request is still being
   processed. The data contains an estimated completion time.

   The Data Length is always 4. The format of the data is shown in
   Figure 12.









Hanna                                                          [Page 26]


Internet Draft          draft-hanna-marp-00.txt             January 1998


                          0 1 2 3 4 5 6 7
                         +-+-+-+-+-+-+-+-+
                         |   Estimated   |
                         |   Completion  |
                         |     Time      |
                         |               |
                         +-+-+-+-+-+-+-+-+

                             Figure 12

4.2.13.1 Estimated Completion Time (4 bytes)

   The Estimated Completion Time is an estimate of when the request will
   be completed. It is an unsigned 32-bit number of seconds from the
   time the progress report is sent. It is NOT a MARP time. See section
   2 for descriptions of how this time is used by the client.

5 Comparison with MDHCP

   Because MDHCP is based on DHCP, it includes several features that
   were required for DHCP's problem set but are not required for
   multicast address allocation. For instance, compatibility with BOOTP
   forwarders.

   MDHCP requires the presence of a DHCP server to get the MDHCP server
   multicast address and multicast scope list (or static configuration).
   MARP uses AAP to find servers, therefore avoiding lots of extra
   complexity.

   A different version of MDHCP will be required to support IPv6.  MARP
   supports both IPv4 and IPv6.

   MDHCP uses the same port number as DHCP on the server, so it will not
   be possible to colocate an MDHCP and DHCP server unless they are the
   same process. MARP does not have this problem.

   Security is crucial for multicast address allocation, but MDHCP does
   not include support for security. It refers to ongoing DHCP security
   work, but this is not complete. MARP includes security support.

   MDHCP uses a single multicast address for all MDHCP servers.  This
   may cause problems when there are different multicast scopes.

   MDHCP requires two multicast packets and two unicast packets for a
   protocol exchange. MARP requires only three unicast packets.

   MDHCP does not include support for a requested interval, just a
   required one.



Hanna                                                          [Page 27]


Internet Draft          draft-hanna-marp-00.txt             January 1998


   MDHCP may be able to leverage some code from DHCP servers.

6 Security Considerations

   Authenticating the MARP client allows for per-user limits on address
   allocation and charging for addresses (if desired), and prevents
   deallocating someone else's address.

   Authenticating the MARP server prevents creating a fake MARP server
   that gives out invalid addresses.

   Caching requests for 2 hours and rejecting requests with a current
   time that differs from the servers by more than 90 minutes prevents
   replay attacks (assuming authentication is required).

   Encryption is somewhat useful, but probably not essential. Knowing
   who is requesting multicast address allocation services and what the
   response is might make it easier for attackers to jam multicast
   sessions. Or simply learning who's doing what might be interesting.

   IPsec or TLS could be used for this application, but IPsec currently
   does not support different security associations for different
   processes on a single machine and TLS would require lots more
   overhead per request.

7 References

   [1]  Handley, M., Thaler, D., and D. Estrin, "The Internet Multicast Address
        Allocation Architecture", draft-handley-malloc-arch-00.txt, Internet
        Draft, December 1997.

   [2]  Patel, B. and M. Shah, "Multicast address allocation extensions to the
        Dynamic Host Configuration Protocol", draft-ietf-dhc-mdhcp-03.txt,
        Internet Draft, November 1997.

   [3]  Handley, M., "Multicast Address Allocation Protocol",
        draft-handley-aap-00.txt, Internet Draft, December 1997.

   [4]  Handley, M., "Multicast Scope Zone Announcement Protocol",
        draft-ietf-mboned-mzap-00.txt, December 1997.

8 Open Issues

   * We need a reserved port number for the MARP server.

   * Do we need to support future allocation (where the server returns a
     token instead of an address)? We could use a new address type for this.




Hanna                                                          [Page 28]


Internet Draft          draft-hanna-marp-00.txt             January 1998


   * We should change AAP so that AAP servers that are willing
     to act as a MARP server send some sort of periodic message when they
     don't have any addresses in use. This is excess multicast traffic,
     but it's no worse than AAP in its stable state.

9 Author's Address

   Steve Hanna
   Sun Microsystems, Inc.
   2 Elizabeth Drive M/S CHL03-205
   Chelmsford, MA 01824

   Tel: +1.978.442.0166
   Fax: +1.978.250.5067
   Email: steve.hanna@sun.com




































Hanna                                                          [Page 29]