MALLOC working group Baiju V. Patel, Intel Corp. Internet Draft Munil Shah, Microsoft Corp. November 1998 Stephen R. Hanna, Sun Microsystems, Inc. Expires: May 1999 draft-ietf-malloc-mdhcp-01.txt Multicast address allocation based on the Dynamic Host Configuration Protocol 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire before February 1999. Distribution of this draft is unlimited. Abstract This document defines a protocol, MDHCP, that allows hosts to request multicast addresses from multicast address allocation servers. MDHCP is similar to DHCP, but not dependent on it. 1. Introduction Multicast address allocation based on the Dynamic Host Configuration Protocol (MDHCP) is a protocol similar to DHCP ([1], [2]) that allows hosts to request multicast address allocation services from multicast address allocation servers. This protocol is part of the Multicast Address Allocation Architecture defined in [5]. However, it may be used separately from the rest of that architecture as appropriate. Patel, Shah, and Hanna [Page 1]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 1.1. Protocol Overview MDHCP is built on a client-server model, where hosts request address allocation services from address allocation servers. See Appendix A for examples of typical protocol exchanges. 1.2. 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. Throughout the rest of this document, the words "server" or "MDHCP server" refer to a host providing multicast address allocation services via MDHCP. The words "client" or "MDHCP client" refer to a host requesting multicast address allocation services via MDHCP. 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. Policy neutral: Allocation policies (such as who can allocate addresses) should not be dictated by the protocol. Patel, Shah, and Hanna [Page 2]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 1.4. Relationship with DHCP In order to allow code reuse, MDHCP is based on a subset of DHCP. However, it has been carefully designed to ensure that there are no dependencies or interactions between the two protocols. MDHCP may be deployed without concern for impacts on existing DHCP servers or clients. As stated above, MDHCP is based on a subset of DHCP. The message format and behavior of the protocols are similar, but there are differences. This specification has been designed to stand on its own, independent of the DHCP specifications. Implementers of MDHCP do not need to read the DHCP specifications, although they may find them useful. Where there are conflicts between the MDHCP and DHCP specifications (and there are several), the MDHCP specifications apply to MDHCP and the DHCP specifications apply to DHCP. Remember, the protocols are similar but independent. 2. Protocol Description The MDHCP 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. Messages are always sent via UDP. A reserved port number dedicated for MDHCP is used on the server (port number 2535, as assigned by IANA). Any port number may be used on client machines. When an MDHCP server sends a message to an MDHCP 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. Like DHCP, MDHCP is a mechanism rather than a policy. MDHCP allows local system administrators to exercise control over configuration parameters where desired. For example, MDHCP servers may be configured to limit the number of multicast addresses allocated to a single client. Properly enforcing such a limit requires cryptographic security, which will be addressed in a supplementary document. All MDHCP messages have the same format. This format is similar to that of a DHCP message. However, many of the fields are unused. Each message includes a message type and a type-length-value encoded options field. The next few sections describe the MDHCP message format and message types. A full list of MDHCP options is provided in section 3. Patel, Shah, and Hanna [Page 3]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 2.1. Message Format The format of an MDHCP message is similar to that of a DHCP message. However, many of the fields are unused. Figure 1 gives the format of an MDHCP message and Table 1 describes each of the fields in the MDHCP 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 MDHCP messages. Any message whose UDP data is too short to hold this format (at least 32 bytes) MUST be ignored. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op (1) | htype (1) | hlen (1) | hops (1) | +---------------+---------------+---------------+---------------+ | xid (4) | +-------------------------------+-------------------------------+ | secs (2) | flags (2) | +-------------------------------+-------------------------------+ | ciaddr (4) | +---------------------------------------------------------------+ | yiaddr (4) | +---------------------------------------------------------------+ | siaddr (4) | +---------------------------------------------------------------+ | giaddr (4) | +---------------------------------------------------------------+ | | | options (variable) | +---------------------------------------------------------------+ Figure 1: Format of an MDHCP message FIELD OCTETS DESCRIPTION ----- ------ ----------- op 1 Message op code / message type. 1 = BOOTREQUEST, 2 = BOOTREPLY htype 1 Should be zero. Ignored. hlen 1 Should be zero. Ignored. hops 1 Must be zero. xid 4 Transaction ID, a random number chosen by the Patel, Shah, and Hanna [Page 4]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 client, used by the client and server to associate messages and responses between a client and a server. secs 2 Must be zero. flags 2 Must be 64 (decimal). ciaddr 4 Must be zero. yiaddr 4 First allocated multicast address (must be zero for Messages from clients). siaddr 4 Must be zero. giaddr 4 Must be zero. options var Optional parameters field. See section 3 for a list of defined options. Table 1: Description of fields in an MDHCP message 2.1.1. MDHCP Message Fields All multi-octet quantities are in network byte-order. The op field of each MDHCP message sent from a client to a server MUST contain BOOTREQUEST (1). BOOTREPLY MUST be used in the op field of each MDHCP message sent from a server to a client. The htype and hlen fields SHOULD be zero. They SHOULD be ignored by MDHCP clients and servers. The hops, secs, ciaddr, siaddr, and giaddr fields MUST have the value zero (0). Messages containing any other value MUST be ignored. The flags field MUST have the value sixty-four decimal (64). Messages containing any other value MUST be ignored. The yiaddr field MUST be set to zero (0) by MDHCP clients. Servers use this field for returning the first allocated Multicast address, as described in section 2.5. 2.1.2. The options field The first four octets of the 'options' field of an MDHCP message MUST have the (decimal) values 99, 130, 83 and 99, respectively. This sequence is known as the "magic cookie". The remainder of the 'options' field consists of a list of tagged parameters that are called "options". Options may be fixed length or variable length. All options begin with a tag (or 'code') octet, which uniquely identifies the option. Fixed-length options without data consist of only a tag octet. Only options 0 and 255 are fixed length. All other options are variable-length with a length octet Patel, Shah, and Hanna [Page 5]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 following the tag octet. The value of the length octet does not include the two octets specifying the tag and length. The length octet is followed by "length" octets of data. In the case of some variable-length options, the length field is a constant but must still be specified. Any options defined subsequent to this document MUST contain a length octet even if the length is fixed or zero. The option field MUST contain the magic cookie defined above, followed by any number of options that are not an end option, and ending with an end option (code 255) followed by any number of pad options (code 0). Any message whose options field does not conform to this syntax MUST be ignored. Anyone sending an MDHCP message SHOULD include only options listed in section 3, but MAY include other MDHCP options that are defined in the future. Anyone receiving an MDHCP message MUST ignore unrecognized options. New MDHCP options may only be defined by submitting a standards track RFC. 2.2. Message Types The "MDHCP message type" option MUST be included in every MDHCP message. This option defines the "type" of the MDHCP message. Throughout this document, MDHCP messages that include an 'MDHCP message type' option will be referred to by the type of the message; e.g., an MDHCP message with 'MDHCP message type' option type 1 will be referred to as an "MDHCPDISCOVER" message. Here are descriptions of the message types a client may send and the way a server should respond. Table 2, which appears at the end of this section, summarizes which options are allowed with each message type. 2.2.1. MDHCPDISCOVER The MDHCPDISCOVER message is used by a MDHCP client that wants to discover MDHCP servers that can probably satisfy a request. MDHCP clients MAY employ other methods to find MDHCP servers, such as caching an IP address that worked in the past or obtaining a DNS name or IP address from DHCP or prior configuration. Using the MDHCPDISCOVER message has the particular advantage that it allows clients to automatically move to another server if one fails. The MDHCP client begins by sending a multicast MDHCPDISCOVER message to an MDHCP server multicast address. Any servers that wish to assist the client respond by sending a unicast MDHCPOFFER message to the client. If a server can process the request with a shorter lease time Patel, Shah, and Hanna [Page 6]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 or later start time than the client requested, it MAY send an MDHCPOFFER message with the lease time that it can offer. After a suitable delay, the client selects the server it wants to use and moves into the request phase. The time over which the client collects messages and the mechanism used to select one MDHCPOFFER are implementation dependent. If no MDHCPOFFER messages are received after an appropriate delay, the client SHOULD resend its MDHCPDISCOVER message. For more details about the MDHCP Server Multicast Address, see section 2.9. 2.2.2. MDHCPREQUEST The MDHCPREQUEST message is used by an MDHCP client that wants to allocate or extend the lease of a multicast address. The MDHCP client sends out an MDHCPREQUEST message. If this request was previously sent as an MDHCPDISCOVER message, the MDHCPREQUEST message SHOULD be multicast to the MDHCP server multicast address so that all MDHCP servers know which server was selected. Otherwise, the MDHCPREQUEST message SHOULD be unicast to the MDHCP server that the client wants to use. If the selected server can process the request successfully, it SHOULD unicast an MDHCPACK message to the client. Otherwise, it SHOULD unicast an MDHCPNAK to the client. If a server can process the request with a shorter lease time or later start time than the client requested, it MAY send an MDHCPACK message with the lease time that it can offer. If the server responds with an MDHCPNAK or fails to respond within a reasonable (implementation-dependent) delay, the client MAY try to find another server by sending an MDHCPDISCOVER request with another xid. 2.2.3 MDHCPRELEASE If a client wants to deallocate a multicast address before its lease expires, the client unicasts an MDHCPRELEASE message to the server from which it allocated the address. The server does not respond to this message. 2.2.2. MDHCPINFORM The MDHCPINFORM message is used by an MDHCP client that wants to acquire configuration parameters. Patel, Shah, and Hanna [Page 7]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 The MDHCP client sends out an MDHCPINFORM message. The message may be unicast to a particular MDHCP server or multicast to the MDHCP server multicast address. If a server receives an MDHCPINFORM message and it can process the request successfully, it SHOULD unicast an MDHCPACK message to the client. The MDHCPACK message SHOULD include the Multicast Scope List option and MAY include the Current Time option. Otherwise, it SHOULD ignore the MDHCPINFORM message. If no MDHCPACK messages are received after an appropriate delay, the client may resend its MDHCPINFORM message to the MDHCP server multicast address. 2.2.4. Options Allowed Table 2 summarizes which options are allowed with each message type. Option MDHCPOFFER MDHCPACK MDHCPNAK ------ ---------- -------- -------- Requested IP Address MUST NOT MUST NOT MUST NOT IP address lease time MUST MUST MUST NOT MDHCP Message Type MUST MUST MUST Server Identifier MUST MAY MAY Client identifier MUST MUST MUST Multicast Scope MUST MUST MUST NOT Start Time MAY MAY MUST NOT Multicast TTL MAY MAY MUST NOT Number of Addresses Requested MAY MAY MUST NOT Requested Language MUST NOT MUST NOT MUST NOT Multicast Scope List MAY MAY MUST NOT List of Address Ranges Allocated MAY MAY MUST NOT Current Time MAY MAY MUST NOT Option MDHCPDISCOVER MDHCPREQUEST MDHCPRELEASE ------ ------------ ----------- ----------- Requested IP Address MAY MAY MUST IP address lease time MAY MAY MUST NOT MDHCP Message Type MUST MUST MUST Server Identifier MUST NOT MUST (if MUST NOT multicast) Client identifier MUST MUST MUST Multicast Scope SHOULD SHOULD MUST NOT Start Time MAY MAY MUST NOT Multicast TTL MUST NOT MUST NOT MUST NOT Number of Addresses Patel, Shah, and Hanna [Page 8]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 Requested MAY MAY MAY Requested Language MAY MAY MUST NOT Multicast Scope List MAY MAY MUST NOT List of Address Ranges Allocated MAY MAY MAY Current Time MAY MAY MUST NOT Option MDHCPINFORM ------ ------------ Requested IP Address MUST NOT IP address lease time MUST NOT MDHCP Message Type MUST Server Identifier MUST NOT Client identifier MUST Multicast Scope MUST NOT Start time MUST NOT Multicast TTL MUST NOT Number of Addresses Requested MUST NOT Requested Language MAY Multicast Scope List MUST NOT List of Address Ranges Allocated MUST NOT Current Time MUST NOT Table 2: Options allowed in MDHCP messages 2.3. Retransmission MDHCP clients are responsible for all message retransmission. The client MUST adopt a retransmission strategy that incorporates a randomized 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. For example, in a 10Mb/sec Ethernet internetwork, the delay before the first retransmission SHOULD be 4 seconds randomized by the value of a uniform random number chosen from the range -1 to +1. Clients with clocks that provide resolution granularity of less than one second may choose a non-integer randomization value. The delay before the next retransmission SHOULD be 8 seconds randomized by the value of a uniform number chosen from the range -1 to +1. The retransmission delay SHOULD be doubled with subsequent retransmissions up to a maximum of 64 seconds. 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. Patel, Shah, and Hanna [Page 9]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 2.4. Associating Client and Server Messages Messages between clients and servers are associated with one another using the client identifier option and xid field. Each client MUST choose a client identifier that is unique within a multicast address allocation domain. For each transaction initiated by a client, the client MUST generate an xid value that is unique for that client identifier and likely to be unique across all client identifiers. For instance, a client might start with a random xid and increment from there. The client identifier option and xid field MUST be included in each message sent by the client or the server. The client MUST check the client identifier option and xid field in each incoming message to ensure that they match its client identifier and an outstanding transaction. If not, the message MUST be discarded. The server MUST check the client identifier option and xid field in each incoming message to establish the proper context for the message. If the message is inappropriate for its context, it SHOULD be discarded. A transaction can be an attempt to allocate a multicast address (consisting of MDHCPDISCOVER, MDHCPOFFER, MDHCPREQUEST, MDHCPACK, and MDHCPNAK messages), an attempt to extend a lease (consisting of MDHCPREQUEST, MDHCPACK, and MDHCPNAK messages), an attempt to release a previously allocated multicast address (consisting of a single MDHCPRELEASE message), or an attempt to acquire configuration parameters (consisting of MDHCPINFORM and MDHCPACK messages). 2.5. Allocating Multiple Addresses An MDHCP client may request the allocation of more than one multicast address in a single request by including the Number of Addresses Requested option in the MDHCPDISCOVER and MDHCPREQUEST messages. An MDHCP server may include this option in an MDHCPOFFER or MDHCPACK message to indicate its willingness to supply more than one address. Finally, an MDHCP client may include this option in an MDHCPRELEASE message to release a set of addresses or in an MDHCPREQUEST message to renewing a lease for a set of addresses. When the Number of Addresses Requested option is included in an MDHCPOFFER or MDHCPACK message, it MUST be accompanied by a List of Address Ranges Allocated option listing the address ranges offered or allocated. This is in addition to the normal requirement that the yiaddr field be set to the first multicast address allocated. When the Number of Addresses Requested option is included in an MDHCPREQUEST message for the purposes of renewing a lease for a set of addresses or in an MDHCPRELEASE message, it MUST be accompanied by Patel, Shah, and Hanna [Page 10]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 a List of Address Ranges Allocated option listing the address ranges affected. This is in addition to the normal requirement that the Requested IP Address option be used to specify the first multicast address allocated. 2.6. Multicast Scopes RFC 2365 [3] provides for dividing the multicast address space into a number of administratively 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), an MDHCP client SHOULD determine that the scope is in effect at its location at this time. Several techniques that an MDHCP client may use to determine the set of administrative scopes in effect (the scope list) are: manual configuration, configuration via MDHCP (using the Multicast Scope List option), or listening to MZAP messages [6]. If an MDHCP client is unable to determine its scope list using one of these techniques, it MAY temporarily assume a scope list consisting of IPv4 Local Scope and IPv4 Allocation Scope, both with a maximum TTL of 16. Using this temporary scope list, it MAY attempt to contact an MDHCP server that can provide a scope list for it. When an MDHCP client requests an address, it SHOULD specify the administrative scope from which the address should be allocated. This scope is indicated with the Multicast Scope option. If no scope is specified, the server MAY allocate an address from some default scope or refuse to allocate an address. In any case, the server MUST include the Multicast Scope option in all MDHCPOFFER and MDHCPACK messages. 2.7. Multicast TTL Another way to limit propagation of multicast messages is by setting the TTL field before sending them. This technique has several disadvantages in comparison to administratively scoped multicast addresses, but it is currently in widespread usage. Patel, Shah, and Hanna [Page 11]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 An MDHCP client MAY request a multicast address for use with a specific TTL by including a Multicast TTL option in an MDHCPDISCOVER or MDHCPREQUEST message. The server SHOULD respond to this option by returning only addresses which support the specified TTL (or greater). If the client does not include this option, the server MUST assume that 255 is indicated. When sending an MDHCPOFFER or MDHCPACK message with a multicast address in it, an MDHCP server MUST indicate the maximum TTL that may be used with the address by including a Multicast TTL option. This is known as the "maximum TTL" associated with that address. When using a multicast address allocated with MDHCP, all hosts SHOULD NOT set the TTL field to a number larger than the maximum TTL associated with that address. 2.8. Locating MDHCP Servers There are several ways for an MDHCP client to locate an MDHCP server. For instance, the client may obtain a DNS name or IP address from DHCP or manual configuration. One particularly convenient technique is for the client to send an MDHCPDISCOVER message to an MDHCP Server Multicast Address and wait for MDHCPOFFER responses. This technique is described in more detail in the next section. 2.9. MDHCP Server Multicast Address Each multicast scope has an associated MDHCP 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. An MDHCP client looking for servers that can provide multicast allocation services MAY send an MDHCPDISCOVER message to an MDHCP Server Multicast Address. Any MDHCP servers listening to this address SHOULD respond with a unicast MDHCPOFFER message to the client if they wish to offer a response. Clients may also send MDHCPINFORM messages in the same manner, with servers responding with MDHCPACK messages if they can supply the requested information. If a client receives no response to a message sent to an MDHCP 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 an MDHCP message to the MDHCP Server Multicast Address associated with the global scope. Patel, Shah, and Hanna [Page 12]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 The MDHCP Server Multicast Address used by a client MAY be established by configuration (manually or via DHCP). If a client has no such configuration, it SHOULD start with the MDHCP Server Multicast Address associated with IPv4 Local Scope. If no response is received on this address, it SHOULD try the MDHCP Server Multicast Address associated with the scope from which it is trying to allocate an address, if the scope is a "small" scope. If this does not succeed, it SHOULD try the MDHCP Server Multicast Address associated with Allocation Scope. This technique allows MDHCP servers to provide services for scopes in which they do not reside. However, such servers MUST make special efforts to ensure that their services meet clients' needs for largely conflict-free allocation and accurate scope list information. In particular, AAP traffic does not extend outside of the scope that is being managed so coordinating with other servers may be difficult. Also, establishing which scope the client is in may be difficult. If an MDHCP server is not prepared to provide services for scopes in which it does not reside, it SHOULD ignore requests whose scope does not match (or is enclosed by) the scope of the MDHCP Server Multicast Address on which the request was received. 2.10. Clock Skew The Current Time option is used to detect and handle clock skew between MDHCP clients and servers. This option SHOULD be included in any MDHCP message that includes an absolute time (such as the Start Time option). It MAY be included in any MDHCPDISCOVER, MDHCPOFFER, MDHCPREQUEST, or MDHCPACK message. Clock skew is a situation where two systems have clocks that are not synchronized. MDHCP servers SHOULD expect and tolerate a small amount of clock skew with their clients (such as an hour) by ensuring that multicast addresses are allocated for an extra hour or so on either side of the lease given to the client. However, large amounts of clock skew require special handling. 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. If an MDHCP server detects substantial clock skew, it SHOULD ignore the client. The server MAY log a message. 2.11. Using MDHCP Without Administrative Scoping Patel, Shah, and Hanna [Page 13]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 MDHCP can be used in an environment that does not have administrative scoping enabled. In such an environment, TTL scoping SHOULD be used. The Multicast Scope List option MAY be used to distribute information about TTL scopes that are enforced with TTL thresholds. MDHCP clients MAY include the Multicast TTL option in MDHCPDISCOVER or MDHCPREQUEST packets. MDHCP servers MUST include the Multicast TTL option in MDHCPOFFER and MDHCPACK packets when the TTL to be used is less than 255. Multicast MDHCPDISCOVER, MDHCPREQUEST, and MDHCPINFORM packets must be carefully managed in a TTL scoped environment to avoid flooding them around the world. MDHCP clients MAY be configured (manually or via DHCP) with an MDHCP Server Multicast Address and appropriate TTL. Alternatively, the MDHCP Server Multicast Addresses associated with the IPv4 Local Scope or IPv4 Allocation Scope may be blocked so that packets sent to them with TTL of 16 are not sent outside a certain boundary. In this case, MDHCP clients need not be configured manually or via DHCP, since their default behavior in choosing an MDHCP Server Multicast Address without configuration is to choose the MDHCP Server Multicast Address associated with the IPv4 Local Scope and, if this fails, IPv4 Allocation Scope, using TTL no more than 16. 3. MDHCP Options The following options are defined for use in MDHCP messages. The options are listed in numerical order. 3.1. Pad Option The pad option can be used to cause subsequent fields to align on word boundaries. The code for the pad option is 0, and its length is 1 octet. Code +-----+ | 0 | +-----+ 3.2. Requested IP Address This option is used in a client request (MDHCPDISCOVER or MDHCPREQUEST) to allow the client to request that a particular multicast address be assigned. The code for this option is 50, and its length is 4. Patel, Shah, and Hanna [Page 14]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 Code Len Address +-----+-----+-----+-----+-----+-----+ | 50 | 4 | a1 | a2 | a3 | a4 | +-----+-----+-----+-----+-----+-----+ 3.3. IP Address Lease Time This option is used in a client request (MDHCPDISCOVER or MDHCPREQUEST) to allow the client to request a lease time for the multicast address. In a server reply (MDHCPOFFER), an MDHCP server uses this option to specify the lease time it is willing to offer. The time is in units of seconds, and is specified as a 32-bit unsigned integer. The code for this option is 51, and its length is 4. Code Len Lease Time +-----+-----+-----+-----+-----+-----+ | 51 | 4 | t1 | t2 | t3 | t4 | +-----+-----+-----+-----+-----+-----+ 3.4. MDHCP Message Type This option is used to convey the type of the MDHCP message. The code for this option is 53, and its length is 1. Legal values for this option are: Value Message Type ----- ------------ 1 MDHCPDISCOVER 2 MDHCPOFFER 3 MDHCPREQUEST 4 reserved 5 MDHCPACK 6 MDHCPNAK 7 MDHCPRELEASE 8 MDHCPINFORM Code Len Type +-----+-----+-----+ | 53 | 1 | 1-8 | +-----+-----+-----+ 3.5. Server Identifier This option is used in MDHCPOFFER and MDHCPREQUEST messages, and may optionally be included in the MDHCPACK and MDHCPNAK messages. MDHCP Patel, Shah, and Hanna [Page 15]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 servers include this option in the MDHCPOFFER in order to allow the client to distinguish between lease offers. MDHCP clients use the contents of the 'server identifier' field as the destination address for any MDHCP messages unicast to the MDHCP server. MDHCP clients also indicate which of several lease offers is being accepted by including this option in an MDHCPREQUEST message. The identifier is the IP address of the selected server. The code for this option is 54, and its length is 4. Code Len Address +-----+-----+-----+-----+-----+-----+ | 54 | 4 | a1 | a2 | a3 | a4 | +-----+-----+-----+-----+-----+-----+ 3.6. Client Identifier This option is used by MDHCP clients to specify their unique identifier. MDHCP servers use this value to index their database of address bindings. This value is expected to be unique for all clients in an administrative domain. Identifiers SHOULD be treated as opaque objects by MDHCP servers. The client identifier MAY consist of type-value pairs similar to the of a hardware type and hardware address. In this case the type field SHOULD be one of the ARP hardware types defined in STD2 [8]. A hardware type of 0 (zero) should be used when the value field contains an identifier other than a hardware address (e.g. a fully qualified domain name). For correct identification of clients, each client's client- identifier MUST be unique among the client-identifiers used on the subnet to which the client is attached. Vendors and system administrators are responsible for choosing client-identifiers that meet this requirement for uniqueness. The code for this option is 61, and its minimum length is 2. Code Len Type Client-Identifier +-----+-----+-----+-----+-----+--- | 61 | n | t1 | i1 | i2 | ... +-----+-----+-----+-----+-----+--- 3.7. Multicast Scope The multicast scope option is used by the client to indicate the Patel, Shah, and Hanna [Page 16]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 multicast scope for the requested multicast address. It is also used to indicate the scope of the assigned address by the MDHCP server. If this option is not specified, the MDHCP server MAY allocate an address from a default scope or reject the request. Code Len Scope ID +-----+-----+-----+-----+-----+-----+ | 101 | 4 | i1 | i2 | i3 | i4 | +-----+-----+-----+-----+-----+-----+ 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 code for this option is 101 and the length is 4. 3.8. Start Time The Start Time option is used in a client request (MDHCPDISCOVER or MDHCPREQUEST) to allow the client to request the starting time for the use of the assigned address. This option allows a client to request a multicast address for use at a future time. Code Len Time +-----+-----+-----+-----+-----+-----+ | 102 | 4 | t1 | t2 | t3 | t4 | +-----+-----+-----+-----+-----+-----+ 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 is consistent with the time format used in AAP [9] and can be converted to an NTP timestamp by adding decimal 2208988800. This time format will not wrap until the year 2106. 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. If the Start Time option is present, the Current Time option MUST also be present, as described in section 2.10. The code for this option is 102 and the length is 4. 3.9. Multicast TTL This option specifies the TTL value to be used with the multicast address. The TTL is specified as an octet with a value between 1 and 255. The implied value of this option is 255 when not included. Patel, Shah, and Hanna [Page 17]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 Code Len Multicast TTL +-----+-----+-----+ | 103 | 1 | n | +-----+-----+-----+ The code for this option is 103 and the length is 1. 3.10. Number of Addresses Requested This option specifies the minimum and desired number of addresses requested by the client. These values are unsigned 16 bit integers stored in network byte order. The minimum MUST be less than or equal to the desired number. If a packet is received where this is not the case, the desired value MUST be used for both. 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. An MDHCP server receiving an MDHCPDISCOVER or MDHCPREQUEST packet including this option MUST include between minimum and desired number of addresses in any MDHCPOFFER or MDHCPACK response. The server MAY use this option to indicate to the client the number of addresses it has allocated to the client. In this case, the minimum and desired values MUST be equal. Code Len Minimum Desired +-----+-----+-----+-----+-----+-----+ | 104 | 4 | min | desired | +-----+-----+-----+-----+-----+-----+ The code for this option is 104 and the length is 4. 3.11. Requested Language This option specifies the language in which the MDHCP client would like strings such as zone names to be returned. It is an RFC 1766 [11] 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. Code Len Language Tag +-----+-----+-----+-...-+-----+ | 110 | n | L1 | | Ln | +-----+-----+-----+-...-+-----+ The code for this option is 110. Patel, Shah, and Hanna [Page 18]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 3.11. Multicast Scope List The format of the multicast scope list option is: Code Len Count Scope List +-----+-----+-----+-----+-...-+-----+ | 107 | p | m | L1 | | Lm | +-----+-----+-----+-----+-...-+-----+ The scope list is a list of m tuples, where each tuple is of the form, Scope ID ( 4 Bytes ) Last Address (4 Bytes ) +-----+-----+-----+-----+-----+-----+-----+-----+ | ID1 | ID2 | ID3 | ID4 | E1 | E2 | E3 | E4 | +-----+-----+-----+-----+-----+-----+-----+-----+ TTL Name Encoded Name List Count +-----+-----+-----+-...-+-----+ | 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). Each encoded name is of the form 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 may be zero), Language Tag is a language tag indicating the language of the zone name (as described in [11]), Name Length is the length of the Name in octets, and Name is a UTF-8 [10] string indicating the name given to the scope zone. 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. Patel, Shah, and Hanna [Page 19]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 The scope IDs of entries in the list SHOULD be unique and the scopes SHOULD be listed from smallest to largest. If the client has not specified a Requested Language option in its request, the MDHCP server SHOULD return all zone names for each zone. If the client has specified a Requested Language option in its request, the MDHCP server MUST return no more than one zone name for each zone. For each zone, the MDHCP 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 MDHCP 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. If the scope list is too long to fit into a single Multicast Scope List option (255 bytes), the server SHOULD split it at 255 bytes and place the remaining bytes in one or more subsequent Multicast Scope List options. The client SHOULD carefully scan the entire set of options and reassemble the scope list by concatenating all Multicast Scope List options before attempting to parse them. The code for this option is 107. 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: Code Len Count +-----+-----+-----+... | 107 | 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 | +---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+... Name Length Name +------+--+--+-...-+--+--+... | 15 | Inside abcd.com | +------+--+--+-...-+--+--+... Patel, Shah, and Hanna [Page 20]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 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 | +------+--...--+ 3.12. List of Address Ranges Allocated This option is used by the server to provide the list of all the address ranges allocated to the client when the client requests more than one address. When a client requests only one address, the server uses the 'yiaddr' field to specify the allocated address. When a client requests more than one address, additional address ranges are listed via this option. This option is also used by the client when requesting a lease extension for more than one address or releasing more than one address. Code Len Address Range List +-----+-----+-----+-----+-...-+-----+ | 108 | n | L1 | L2 | | Ln | +-----+-----+-----+-----+-----+-----+ where the Address Range List is of the following format. StartAddress1 BlockSize1 StartAddress2 BlockSize2 ... +---+---+---+---+---+---+---+---+---+---+---+---+--...--+ |S11|S12|S13|S14|B11|B12|S21|S22|S23|S24|B21|B22| | +---+---+---+---+---+---+---+---+---+---+---+---+-------+ The code for this option is 108 and the minimum length is 6. 3.13. Current Time The current time may be used to express what the sender thinks the current time is. This option may be used to detect clock skew and MUST be used if the Start Time option is used, as described in section 2.10. Patel, Shah, and Hanna [Page 21]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 Code Len Time +-----+-----+-----+-----+-----+-----+ | 109 | 4 | t1 | t2 | t3 | t4 | +-----+-----+-----+-----+-----+-----+ 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 is consistent with the time format used in AAP [9] and can be converted to an NTP [4] timestamp by adding decimal 2208988800. This time format will not wrap until the year 2106. The code for this option is 109 and the length is 4. 3.14. End Option The end option marks the end of valid information in the vendor field. Subsequent octets should be filled with pad options. The code for this option is 255, and the length is 1. Code +-----+ | 255 | +-----+ 4. Open Issues and Action Items We refer to Allocation Scope, but this has not been assigned by IANA yet. If this is still the case when we want to go to Proposed Standard, we will have to remove these references. 5. Security Considerations There are several security risks associated with multicast address allocation. First, multicast addresses are a scarce commodity. Therefore, it may be desirable or necessary to provide access controls on allocation services. Enforcing such controls requires client authentication with replay prevention. Second, there are many possibilities for denial of service. Allocating excessive numbers of addresses may be addressed by providing access controls as described above. Deallocating or modifying other clients' addresses may be handled in a similar way. Installing a false server can be addressed by requiring clients to authenticate servers. Patel, Shah, and Hanna [Page 22]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 Third, information about who has allocated what may disclose confidential information and may be useful in other attacks such as sending extra data to your enemies' multicast groups. Providing confidentiality via encryption addresses those problems somewhat, although traffic analysis is still possible. There are already efforts underway in the DHC Working Group that should be helpful with these problems. The authors are monitoring this work and hope to apply the solutions developed there in this context. 6. Acknowledgments 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. Much of the text in this document is based on or copied from [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. 7. References [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [3] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998. [4] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992. [5] Handley, M., D. Thaler, and D. Estrin, "The Internet Multicast Address Allocation Architecture", Internet Draft, draft-handley- malloc-arch-00.txt, December 1997. [6] Handley, M., "Multicast-Scope Zone Announcement Protocol (MZAP)", Internet Draft, draft-ietf-mboned-mzap-00.txt, December 1997. [7] Croft, W., and J. Gilmore, "Bootstrap Protocol", RFC 951, Stanford University and Sun Microsystems, September 1985. Patel, Shah, and Hanna [Page 23]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 [8] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, July 1992. [9] Handley, M., "Multicast Address Allocation Protocol (AAP)", Internet Draft, draft-handley-aap-00.txt, December 1997. [10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [11] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. 8. Authors' Addresses Baiju V. Patel Intel Corp. 2111 NE 25th Ave. Hillsboro, OR 97124 Phone: 503 264 2422 EMail: baiju.v.patel@intel.com Munil Shah Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 425 703 3924 Email: munils@microsoft.com Stephen R. Hanna Sun Microsystems, Inc. 2 Elizabeth Drive, M/S UCHL03-205 Chelmsford, MA 01824 Phone: +1.978.442.0166 Email: steve.hanna@sun.com APPENDIX A: Examples This appendix includes several examples of typical MDHCP protocol exchanges. 1. Unicast Address Allocation In this example, an MDHCP client wants to allocate a multicast address from the global scope for use during the next two hours. It knows (through prior configuration or communication) the scopes that Patel, Shah, and Hanna [Page 24]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 are in effect at its location and the unicast address of an MDHCP server that provides allocation services for the global scope. The client begins by unicasting an MDHCPREQUEST packet to the server. This packet includes the IP Address Lease Time, MDHCP Message Type, Client Identifier, and Multicast Scope options. The server responds with an MDHCPACK packet containing the requested address. The address is stored in the yiaddr field. This packet includes the IP Address Lease Time, MDHCP Message Type, Client Identifier, and Multicast Scope options. At this time, the client is said to have a two hour "lease" on the multicast address, indicating that (with high likelihood) this address will not be allocated to any other clients in the same scope for use during this period. The client may then proceed to distribute the address to others and conduct a multicast session on the address. If the client had not received a response from the server, it would probably have retransmitted its MDHCPREQUEST packet for a while. If it still received no response, it could try another server or move to multicast discovery with the MDHCPDISCOVER message. The following figure illustrates this exchange. Patel, Shah, and Hanna [Page 25]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 Client Server v v | | |\_____________ | | MDHCPREQUEST \| | | | Commits address | | | _____________/| |/ MDHCPACK | | | | | v v Figure 2: Timeline diagram of messages exchanged in Unicast Address Allocation example 2. Lease Extension 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 an MDHCPREQUEST packet to the server from which it allocated the address. This packet includes the Requested IP Address, IP Address Lease Time, MDHCP Message Type, and Client Identifier options. The time included in the IP Address Lease Time is two hours, since the client wants the lease to expire two hours from the current time. The server responds with an MDHCPACK packet indicating that the lease extension has been granted. The address is stored in the yiaddr field. This packet includes the IP Address Lease Time, MDHCP Message Type, Client Identifier, and Multicast Scope options. If the server did not want to grant the requested lease extension, it would have responded with an MDHCPACK packet with the remaining lease time indicated in the IP Address Lease Time option. It would *not* send an MDHCPNAK packet, since that would cancel the lease immediately. The following figure illustrates this exchange. Patel, Shah, and Hanna [Page 26]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 Client Server v v | | |\_____________ | | MDHCPREQUEST \| | | | Extends lease | | | _____________/| |/ MDHCPACK | | | | | v v Figure 3: Timeline diagram of messages exchanged in Lease Extension example 3. Address Release 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 an MDHCPRELEASE packet to the server from which it allocated the address. This packet includes the Requested IP Address, MDHCP Message Type, and Client Identifier options. When the server receives this packet, it cancels the client's lease on the address. Since the server does not acknowledge the MDHCPRELEASE packet, there is no provision for the client retransmitting it. However, this is not very harmful. If an MDHCPRELEASE packet is lost, the server will keep the multicast address reserved for the client's use until the end of its lease. At that point, the address will once again be available for use by others. The following figure illustrates this exchange. Patel, Shah, and Hanna [Page 27]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 Client Server v v | | |\_____________ | | MDHCPRELEASE \| | | | Cancels lease | | v v Figure 4: Timeline diagram of messages exchanged in Address Release example 4. Multicast Discovery and Address Allocation Let's revisit the first example, but say that the MDHCP client did not know the unicast address of the MDHCP server that it wanted to use. The client begins by multicasting an MDHCPDISCOVER packet to an MDHCP Server Multicast Address. This packet includes the IP Address Lease Time, MDHCP Message Type, Client Identifier, and Multicast Scope options. Any servers that receive the MDHCPDISCOVER packet and can satisfy this request temporarily reserve an address for the client and unicast an MDHCPOFFER packet to the client. These packets contain the IP Address Lease Time, MDHCP Message Type, Server Identifier, Client Identifier, and Multicast Scope options. The reserved address is also stored in the yiaddr field. After a suitable delay, the client multicasts an MDHCPREQUEST packet to the MDHCP Server Multicast Address. This packet contains all of the options included in the MDHCPDISCOVER packet, but also includes the Server Identifier option, indicating which server it has selected for the request. The server whose Server Identifier matches the one specified by the client responds with an MDHCPACK packet containing the same information as the MDHCPOFFER packet. All the other servers that had sent MDHCPOFFER packets stop reserving an address for the client and forget about the whole exchange. The client now has a two hour "lease" on the multicast address, just like it did in the first example. If the client had not received a response from the server, it would have retransmitted its MDHCPREQUEST packet for a while. If it still Patel, Shah, and Hanna [Page 28]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 received no response, it could try another server or return to multicast discovery with a new MDHCPDISCOVER message. The following figure illustrates this exchange. Server Client Server (not selected) (selected) v v v | | | |Begin multicast address request| | | | | _____________/|\_____________ | |/MDHCPDISCOVER | MDHCPDISCOVER\| | | | Reserves | Reserves Address | Address | | | |\ | ____________/| | \_________ | /MDHCPOFFER | | MDHCPOFFER\ |/ | | \ | | | Collects replies | | \| | | Selects Address | | | | | _____________/|\_____________ | |/ MDHCPREQUEST | MDHCPREQUEST \| | | | | | Commits address | | | | | _____________/| | |/ MDHCPACK | | | | | assignment complete | | | | v v v Figure 5: Timeline diagram of messages exchanged in Multicast Discovery and Address Allocation example APPENDIX B: Change Log CHANGES FROM draft-ietf-malloc-mdhcp-00.txt Port number assigned. Removed unused chaddr, sname, and file fields. Patel, Shah, and Hanna [Page 29]
Internet Draft draft-ietf-malloc-mdhcp-01.txt November 1998 Split MDHCP option space from DHCP. Changed technique for choosing MDHCP Server Multicast Addresses when initial requests fail. Added Requested Language option. Added language tags and multiple names per zone to the Multicast Scope List option. CHANGES FROM draft-ietf-dhc-mdhcp-03.txt Many changes to make this document no longer dependent on the DHCP spec. This should make the document easier to read and understand. Removed MDHCPDECLINE. Added Current Time option to deal with clock skew. Scopes are now identified by the first multicast address in the scope instead of using a scope ID. Changed Total Addresses Requested option to Number of Addresses Requested. Changed this option to have minimum and desired fields. Clarified that servers MAY send MDHCPOFFER or MDHCPACK messages with shorter lifetimes or later start times than those requested by the client. This is consistent with DHCP and provides a simple way to achieve the minimum/maximum lifetime functionality described in the malloc abstract API. Patel, Shah, and Hanna [Page 30]
