idnits 2.17.1 draft-ietf-malloc-mdhcp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 126: '...MDHCP client, it MUST use a destinatio...' RFC 2119 keyword, line 157: '... 32 bytes) MUST be ignored....' RFC 2119 keyword, line 212: '... MUST contain BOOTREQUEST (1). BOOTR...' RFC 2119 keyword, line 215: '... and hlen fields SHOULD be zero. They ...' RFC 2119 keyword, line 218: '... and giaddr fields MUST have the value...' (135 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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 document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '7' is defined on line 1099, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1305 (ref. '4') (Obsoleted by RFC 5905) -- No information found for draft-handley-malloc-arch - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-06) exists of draft-ietf-mboned-mzap-00 ** Downref: Normative reference to an Historic draft: draft-ietf-mboned-mzap (ref. '6') ** Obsolete normative reference: RFC 1700 (ref. '8') (Obsoleted by RFC 3232) -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 2279 (ref. '10') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 1766 (ref. '11') (Obsoleted by RFC 3066, RFC 3282) Summary: 15 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MALLOC working group Baiju V. Patel, Intel Corp. 3 Internet Draft Munil Shah, Microsoft Corp. 4 November 1998 Stephen R. Hanna, Sun Microsystems, Inc. 5 Expires: May 1999 draft-ietf-malloc-mdhcp-01.txt 7 Multicast address allocation based on the 8 Dynamic Host Configuration Protocol 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a "working 21 draft" or "work in progress". 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 26 munnari.oz.au. 28 A revised version of this draft document will be submitted to the RFC 29 editor as a Proposed Standard for the Internet Community. Discussion 30 and suggestions for improvement are requested. This document will 31 expire before February 1999. Distribution of this draft is unlimited. 33 Abstract 35 This document defines a protocol, MDHCP, that allows hosts to request 36 multicast addresses from multicast address allocation servers. MDHCP 37 is similar to DHCP, but not dependent on it. 39 1. Introduction 41 Multicast address allocation based on the Dynamic Host Configuration 42 Protocol (MDHCP) is a protocol similar to DHCP ([1], [2]) that allows 43 hosts to request multicast address allocation services from multicast 44 address allocation servers. This protocol is part of the Multicast 45 Address Allocation Architecture defined in [5]. However, it may be 46 used separately from the rest of that architecture as appropriate. 48 1.1. Protocol Overview 50 MDHCP is built on a client-server model, where hosts request address 51 allocation services from address allocation servers. See Appendix A 52 for examples of typical protocol exchanges. 54 1.2. Terminology 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and"OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119. 60 Throughout the rest of this document, the words "server" or "MDHCP 61 server" refer to a host providing multicast address allocation 62 services via MDHCP. The words "client" or "MDHCP client" refer to a 63 host requesting multicast address allocation services via MDHCP. 65 1.3. Motivation and Protocol Requirements 67 For multicast applications to be deployed everywhere, there is a need 68 to define a protocol that any host may use to allocate multicast 69 addresses. Here are the requirements for such a protocol. 71 Quick response: The host should be able to allocate a multicast 72 address and begin to use it promptly. 74 Low network load: Hosts that are not allocating or deallocating 75 multicast addresses at the present time should not need to send or 76 receive any network traffic. 78 Support for intermittently connected or power managed systems: Hosts 79 should be able to be disconnected from the network, powered off, or 80 otherwise inaccessible except during the brief period during which 81 they are allocating a multicast address. 83 Multicast address scopes: The protocol must be able to allocate both 84 the administratively scoped and globally scoped multicast addresses. 86 Efficient use of address space: The multicast address space is fairly 87 small. The protocol should make efficient use of this scarce 88 resource. 90 Authentication: Because multicast addresses are scarce, it is 91 important to protect against hoarding of these addresses. One way to 92 do this is by authenticating clients. 94 Policy neutral: Allocation policies (such as who can allocate 95 addresses) should not be dictated by the protocol. 97 1.4. Relationship with DHCP 99 In order to allow code reuse, MDHCP is based on a subset of DHCP. 100 However, it has been carefully designed to ensure that there are no 101 dependencies or interactions between the two protocols. MDHCP may be 102 deployed without concern for impacts on existing DHCP servers or 103 clients. 105 As stated above, MDHCP is based on a subset of DHCP. The message 106 format and behavior of the protocols are similar, but there are 107 differences. This specification has been designed to stand on its 108 own, independent of the DHCP specifications. Implementers of MDHCP do 109 not need to read the DHCP specifications, although they may find them 110 useful. 112 Where there are conflicts between the MDHCP and DHCP specifications 113 (and there are several), the MDHCP specifications apply to MDHCP and 114 the DHCP specifications apply to DHCP. Remember, the protocols are 115 similar but independent. 117 2. Protocol Description 119 The MDHCP protocol is a client-server protocol. In general, the 120 client unicasts or multicasts a message to one or more servers, which 121 optionally respond with messages unicast to the client. 123 Messages are always sent via UDP. A reserved port number dedicated 124 for MDHCP is used on the server (port number 2535, as assigned by 125 IANA). Any port number may be used on client machines. When an MDHCP 126 server sends a message to an MDHCP client, it MUST use a destination 127 port number that matches the source port number provided by the 128 client in the message that caused the server to send its message. 130 Like DHCP, MDHCP is a mechanism rather than a policy. MDHCP allows 131 local system administrators to exercise control over configuration 132 parameters where desired. For example, MDHCP servers may be 133 configured to limit the number of multicast addresses allocated to a 134 single client. Properly enforcing such a limit requires cryptographic 135 security, which will be addressed in a supplementary document. 137 All MDHCP messages have the same format. This format is similar to 138 that of a DHCP message. However, many of the fields are unused. Each 139 message includes a message type and a type-length-value encoded 140 options field. 142 The next few sections describe the MDHCP message format and message 143 types. A full list of MDHCP options is provided in section 3. 145 2.1. Message Format 147 The format of an MDHCP message is similar to that of a DHCP message. 148 However, many of the fields are unused. 150 Figure 1 gives the format of an MDHCP message and Table 1 describes 151 each of the fields in the MDHCP message. The numbers in parentheses 152 indicate the size of each field in octets. The names for the fields 153 given in the figure will be used throughout this document to refer to 154 the fields in MDHCP messages. 156 Any message whose UDP data is too short to hold this format (at least 157 32 bytes) MUST be ignored. 159 0 1 2 3 160 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | op (1) | htype (1) | hlen (1) | hops (1) | 164 +---------------+---------------+---------------+---------------+ 165 | xid (4) | 166 +-------------------------------+-------------------------------+ 167 | secs (2) | flags (2) | 168 +-------------------------------+-------------------------------+ 169 | ciaddr (4) | 170 +---------------------------------------------------------------+ 171 | yiaddr (4) | 172 +---------------------------------------------------------------+ 173 | siaddr (4) | 174 +---------------------------------------------------------------+ 175 | giaddr (4) | 176 +---------------------------------------------------------------+ 177 | | 178 | options (variable) | 179 +---------------------------------------------------------------+ 181 Figure 1: Format of an MDHCP message 183 FIELD OCTETS DESCRIPTION 184 ----- ------ ----------- 186 op 1 Message op code / message type. 187 1 = BOOTREQUEST, 2 = BOOTREPLY 188 htype 1 Should be zero. Ignored. 189 hlen 1 Should be zero. Ignored. 190 hops 1 Must be zero. 191 xid 4 Transaction ID, a random number chosen by the 192 client, used by the client and server to associate 193 messages and responses between a client and a 194 server. 195 secs 2 Must be zero. 196 flags 2 Must be 64 (decimal). 197 ciaddr 4 Must be zero. 198 yiaddr 4 First allocated multicast address (must be zero for 199 Messages from clients). 200 siaddr 4 Must be zero. 201 giaddr 4 Must be zero. 202 options var Optional parameters field. See section 3 203 for a list of defined options. 205 Table 1: Description of fields in an MDHCP message 207 2.1.1. MDHCP Message Fields 209 All multi-octet quantities are in network byte-order. 211 The op field of each MDHCP message sent from a client to a server 212 MUST contain BOOTREQUEST (1). BOOTREPLY MUST be used in the op field 213 of each MDHCP message sent from a server to a client. 215 The htype and hlen fields SHOULD be zero. They SHOULD be ignored by 216 MDHCP clients and servers. 218 The hops, secs, ciaddr, siaddr, and giaddr fields MUST have the value 219 zero (0). Messages containing any other value MUST be ignored. 221 The flags field MUST have the value sixty-four decimal (64). Messages 222 containing any other value MUST be ignored. 224 The yiaddr field MUST be set to zero (0) by MDHCP clients. Servers 225 use this field for returning the first allocated Multicast address, 226 as described in section 2.5. 228 2.1.2. The options field 230 The first four octets of the 'options' field of an MDHCP message MUST 231 have the (decimal) values 99, 130, 83 and 99, respectively. This 232 sequence is known as the "magic cookie". 234 The remainder of the 'options' field consists of a list of tagged 235 parameters that are called "options". Options may be fixed length or 236 variable length. All options begin with a tag (or 'code') octet, 237 which uniquely identifies the option. Fixed-length options without 238 data consist of only a tag octet. Only options 0 and 255 are fixed 239 length. All other options are variable-length with a length octet 240 following the tag octet. The value of the length octet does not 241 include the two octets specifying the tag and length. The length 242 octet is followed by "length" octets of data. In the case of some 243 variable-length options, the length field is a constant but must 244 still be specified. Any options defined subsequent to this document 245 MUST contain a length octet even if the length is fixed or zero. 247 The option field MUST contain the magic cookie defined above, 248 followed by any number of options that are not an end option, and 249 ending with an end option (code 255) followed by any number of pad 250 options (code 0). Any message whose options field does not conform to 251 this syntax MUST be ignored. 253 Anyone sending an MDHCP message SHOULD include only options listed in 254 section 3, but MAY include other MDHCP options that are defined in 255 the future. Anyone receiving an MDHCP message MUST ignore 256 unrecognized options. New MDHCP options may only be defined by 257 submitting a standards track RFC. 259 2.2. Message Types 261 The "MDHCP message type" option MUST be included in every MDHCP 262 message. This option defines the "type" of the MDHCP message. 264 Throughout this document, MDHCP messages that include an 'MDHCP 265 message type' option will be referred to by the type of the message; 266 e.g., an MDHCP message with 'MDHCP message type' option type 1 will 267 be referred to as an "MDHCPDISCOVER" message. 269 Here are descriptions of the message types a client may send and the 270 way a server should respond. Table 2, which appears at the end of 271 this section, summarizes which options are allowed with each message 272 type. 274 2.2.1. MDHCPDISCOVER 276 The MDHCPDISCOVER message is used by a MDHCP client that wants to 277 discover MDHCP servers that can probably satisfy a request. MDHCP 278 clients MAY employ other methods to find MDHCP servers, such as 279 caching an IP address that worked in the past or obtaining a DNS name 280 or IP address from DHCP or prior configuration. Using the 281 MDHCPDISCOVER message has the particular advantage that it allows 282 clients to automatically move to another server if one fails. 284 The MDHCP client begins by sending a multicast MDHCPDISCOVER message 285 to an MDHCP server multicast address. Any servers that wish to assist 286 the client respond by sending a unicast MDHCPOFFER message to the 287 client. If a server can process the request with a shorter lease time 288 or later start time than the client requested, it MAY send an 289 MDHCPOFFER message with the lease time that it can offer. 291 After a suitable delay, the client selects the server it wants to use 292 and moves into the request phase. The time over which the client 293 collects messages and the mechanism used to select one MDHCPOFFER are 294 implementation dependent. If no MDHCPOFFER messages are received 295 after an appropriate delay, the client SHOULD resend its 296 MDHCPDISCOVER message. 298 For more details about the MDHCP Server Multicast Address, see 299 section 2.9. 301 2.2.2. MDHCPREQUEST 303 The MDHCPREQUEST message is used by an MDHCP client that wants to 304 allocate or extend the lease of a multicast address. 306 The MDHCP client sends out an MDHCPREQUEST message. If this request 307 was previously sent as an MDHCPDISCOVER message, the MDHCPREQUEST 308 message SHOULD be multicast to the MDHCP server multicast address so 309 that all MDHCP servers know which server was selected. Otherwise, the 310 MDHCPREQUEST message SHOULD be unicast to the MDHCP server that the 311 client wants to use. 313 If the selected server can process the request successfully, it 314 SHOULD unicast an MDHCPACK message to the client. Otherwise, it 315 SHOULD unicast an MDHCPNAK to the client. If a server can process the 316 request with a shorter lease time or later start time than the client 317 requested, it MAY send an MDHCPACK message with the lease time that 318 it can offer. 320 If the server responds with an MDHCPNAK or fails to respond within a 321 reasonable (implementation-dependent) delay, the client MAY try to 322 find another server by sending an MDHCPDISCOVER request with another 323 xid. 325 2.2.3 MDHCPRELEASE 327 If a client wants to deallocate a multicast address before its lease 328 expires, the client unicasts an MDHCPRELEASE message to the server 329 from which it allocated the address. The server does not respond to 330 this message. 332 2.2.2. MDHCPINFORM 334 The MDHCPINFORM message is used by an MDHCP client that wants to 335 acquire configuration parameters. 337 The MDHCP client sends out an MDHCPINFORM message. The message may be 338 unicast to a particular MDHCP server or multicast to the MDHCP server 339 multicast address. 341 If a server receives an MDHCPINFORM message and it can process the 342 request successfully, it SHOULD unicast an MDHCPACK message to the 343 client. The MDHCPACK message SHOULD include the Multicast Scope List 344 option and MAY include the Current Time option. Otherwise, it SHOULD 345 ignore the MDHCPINFORM message. 347 If no MDHCPACK messages are received after an appropriate delay, the 348 client may resend its MDHCPINFORM message to the MDHCP server 349 multicast address. 351 2.2.4. Options Allowed 353 Table 2 summarizes which options are allowed with each message type. 355 Option MDHCPOFFER MDHCPACK MDHCPNAK 356 ------ ---------- -------- -------- 357 Requested IP Address MUST NOT MUST NOT MUST NOT 358 IP address lease time MUST MUST MUST NOT 359 MDHCP Message Type MUST MUST MUST 360 Server Identifier MUST MAY MAY 361 Client identifier MUST MUST MUST 362 Multicast Scope MUST MUST MUST NOT 363 Start Time MAY MAY MUST NOT 364 Multicast TTL MAY MAY MUST NOT 365 Number of Addresses 366 Requested MAY MAY MUST NOT 367 Requested Language MUST NOT MUST NOT MUST NOT 368 Multicast Scope List MAY MAY MUST NOT 369 List of Address Ranges 370 Allocated MAY MAY MUST NOT 371 Current Time MAY MAY MUST NOT 373 Option MDHCPDISCOVER MDHCPREQUEST MDHCPRELEASE 374 ------ ------------ ----------- ----------- 375 Requested IP Address MAY MAY MUST 376 IP address lease time MAY MAY MUST NOT 377 MDHCP Message Type MUST MUST MUST 378 Server Identifier MUST NOT MUST (if MUST NOT 379 multicast) 380 Client identifier MUST MUST MUST 381 Multicast Scope SHOULD SHOULD MUST NOT 382 Start Time MAY MAY MUST NOT 383 Multicast TTL MUST NOT MUST NOT MUST NOT 384 Number of Addresses 385 Requested MAY MAY MAY 386 Requested Language MAY MAY MUST NOT 387 Multicast Scope List MAY MAY MUST NOT 388 List of Address Ranges 389 Allocated MAY MAY MAY 390 Current Time MAY MAY MUST NOT 392 Option MDHCPINFORM 393 ------ ------------ 394 Requested IP Address MUST NOT 395 IP address lease time MUST NOT 396 MDHCP Message Type MUST 397 Server Identifier MUST NOT 398 Client identifier MUST 399 Multicast Scope MUST NOT 400 Start time MUST NOT 401 Multicast TTL MUST NOT 402 Number of Addresses 403 Requested MUST NOT 404 Requested Language MAY 405 Multicast Scope List MUST NOT 406 List of Address Ranges 407 Allocated MUST NOT 408 Current Time MUST NOT 410 Table 2: Options allowed in MDHCP messages 412 2.3. Retransmission 414 MDHCP clients are responsible for all message retransmission. The 415 client MUST adopt a retransmission strategy that incorporates a 416 randomized exponential backoff algorithm to determine the delay 417 between retransmissions. The delay between retransmissions SHOULD be 418 chosen to allow sufficient time for replies from the server to be 419 delivered based on the characteristics of the internetwork between 420 the client and the server. For example, in a 10Mb/sec Ethernet 421 internetwork, the delay before the first retransmission SHOULD be 4 422 seconds randomized by the value of a uniform random number chosen 423 from the range -1 to +1. Clients with clocks that provide resolution 424 granularity of less than one second may choose a non-integer 425 randomization value. The delay before the next retransmission SHOULD 426 be 8 seconds randomized by the value of a uniform number chosen from 427 the range -1 to +1. The retransmission delay SHOULD be doubled with 428 subsequent retransmissions up to a maximum of 64 seconds. The client 429 MAY provide an indication of retransmission attempts to the user as 430 an indication of the progress of the process. The client MAY halt 431 retransmission at any point. 433 2.4. Associating Client and Server Messages 435 Messages between clients and servers are associated with one another 436 using the client identifier option and xid field. Each client MUST 437 choose a client identifier that is unique within a multicast address 438 allocation domain. For each transaction initiated by a client, the 439 client MUST generate an xid value that is unique for that client 440 identifier and likely to be unique across all client identifiers. For 441 instance, a client might start with a random xid and increment from 442 there. The client identifier option and xid field MUST be included in 443 each message sent by the client or the server. 445 The client MUST check the client identifier option and xid field in 446 each incoming message to ensure that they match its client identifier 447 and an outstanding transaction. If not, the message MUST be 448 discarded. The server MUST check the client identifier option and xid 449 field in each incoming message to establish the proper context for 450 the message. If the message is inappropriate for its context, it 451 SHOULD be discarded. 453 A transaction can be an attempt to allocate a multicast address 454 (consisting of MDHCPDISCOVER, MDHCPOFFER, MDHCPREQUEST, MDHCPACK, and 455 MDHCPNAK messages), an attempt to extend a lease (consisting of 456 MDHCPREQUEST, MDHCPACK, and MDHCPNAK messages), an attempt to release 457 a previously allocated multicast address (consisting of a single 458 MDHCPRELEASE message), or an attempt to acquire configuration 459 parameters (consisting of MDHCPINFORM and MDHCPACK messages). 461 2.5. Allocating Multiple Addresses 463 An MDHCP client may request the allocation of more than one multicast 464 address in a single request by including the Number of Addresses 465 Requested option in the MDHCPDISCOVER and MDHCPREQUEST messages. An 466 MDHCP server may include this option in an MDHCPOFFER or MDHCPACK 467 message to indicate its willingness to supply more than one address. 468 Finally, an MDHCP client may include this option in an MDHCPRELEASE 469 message to release a set of addresses or in an MDHCPREQUEST message 470 to renewing a lease for a set of addresses. 472 When the Number of Addresses Requested option is included in an 473 MDHCPOFFER or MDHCPACK message, it MUST be accompanied by a List of 474 Address Ranges Allocated option listing the address ranges offered or 475 allocated. This is in addition to the normal requirement that the 476 yiaddr field be set to the first multicast address allocated. 478 When the Number of Addresses Requested option is included in an 479 MDHCPREQUEST message for the purposes of renewing a lease for a set 480 of addresses or in an MDHCPRELEASE message, it MUST be accompanied by 481 a List of Address Ranges Allocated option listing the address ranges 482 affected. This is in addition to the normal requirement that the 483 Requested IP Address option be used to specify the first multicast 484 address allocated. 486 2.6. Multicast Scopes 488 RFC 2365 [3] provides for dividing the multicast address space into a 489 number of administratively scopes. Routers should be configured so 490 that each scope corresponds to a particular partition of the network 491 into disjoint regions. Messages sent to a multicast address that 492 falls within a certain administrative scope should only be delivered 493 to hosts that have joined that multicast group *and* fall within the 494 same region as the sender. For instance, packets sent to an address 495 in the organization-local scope should only be delivered to hosts 496 that have joined that group and fall within the same organization as 497 the sender. 499 Different sets of scopes may be in effect at different places in the 500 network and at different times. Before attempting to allocate an 501 address from an administrative scope (other than global or link- 502 level scope, which are always in effect), an MDHCP client SHOULD 503 determine that the scope is in effect at its location at this time. 504 Several techniques that an MDHCP client may use to determine the set 505 of administrative scopes in effect (the scope list) are: manual 506 configuration, configuration via MDHCP (using the Multicast Scope 507 List option), or listening to MZAP messages [6]. 509 If an MDHCP client is unable to determine its scope list using one of 510 these techniques, it MAY temporarily assume a scope list consisting 511 of IPv4 Local Scope and IPv4 Allocation Scope, both with a maximum 512 TTL of 16. Using this temporary scope list, it MAY attempt to contact 513 an MDHCP server that can provide a scope list for it. 515 When an MDHCP client requests an address, it SHOULD specify the 516 administrative scope from which the address should be allocated. This 517 scope is indicated with the Multicast Scope option. If no scope is 518 specified, the server MAY allocate an address from some default scope 519 or refuse to allocate an address. In any case, the server MUST 520 include the Multicast Scope option in all MDHCPOFFER and MDHCPACK 521 messages. 523 2.7. Multicast TTL 525 Another way to limit propagation of multicast messages is by setting 526 the TTL field before sending them. This technique has several 527 disadvantages in comparison to administratively scoped multicast 528 addresses, but it is currently in widespread usage. 530 An MDHCP client MAY request a multicast address for use with a 531 specific TTL by including a Multicast TTL option in an MDHCPDISCOVER 532 or MDHCPREQUEST message. The server SHOULD respond to this option by 533 returning only addresses which support the specified TTL (or 534 greater). If the client does not include this option, the server 535 MUST assume that 255 is indicated. 537 When sending an MDHCPOFFER or MDHCPACK message with a multicast 538 address in it, an MDHCP server MUST indicate the maximum TTL that may 539 be used with the address by including a Multicast TTL option. This is 540 known as the "maximum TTL" associated with that address. 542 When using a multicast address allocated with MDHCP, all hosts SHOULD 543 NOT set the TTL field to a number larger than the maximum TTL 544 associated with that address. 546 2.8. Locating MDHCP Servers 548 There are several ways for an MDHCP client to locate an MDHCP server. 549 For instance, the client may obtain a DNS name or IP address from 550 DHCP or manual configuration. 552 One particularly convenient technique is for the client to send an 553 MDHCPDISCOVER message to an MDHCP Server Multicast Address and wait 554 for MDHCPOFFER responses. This technique is described in more detail 555 in the next section. 557 2.9. MDHCP Server Multicast Address 559 Each multicast scope has an associated MDHCP Server Multicast 560 Address. This address has been reserved by the IANA as the address 561 with a relative offset of -1 from the last address of a multicast 562 scope. 564 An MDHCP client looking for servers that can provide multicast 565 allocation services MAY send an MDHCPDISCOVER message to an MDHCP 566 Server Multicast Address. Any MDHCP servers listening to this address 567 SHOULD respond with a unicast MDHCPOFFER message to the client if 568 they wish to offer a response. Clients may also send MDHCPINFORM 569 messages in the same manner, with servers responding with MDHCPACK 570 messages if they can supply the requested information. 572 If a client receives no response to a message sent to an MDHCP Server 573 Multicast Address (after retransmission), it MAY send the message to 574 a larger scope and repeat this process as necessary. However, the 575 client MUST NOT send an MDHCP message to the MDHCP Server Multicast 576 Address associated with the global scope. 578 The MDHCP Server Multicast Address used by a client MAY be 579 established by configuration (manually or via DHCP). If a client has 580 no such configuration, it SHOULD start with the MDHCP Server 581 Multicast Address associated with IPv4 Local Scope. If no response is 582 received on this address, it SHOULD try the MDHCP Server Multicast 583 Address associated with the scope from which it is trying to allocate 584 an address, if the scope is a "small" scope. If this does not 585 succeed, it SHOULD try the MDHCP Server Multicast Address associated 586 with Allocation Scope. 588 This technique allows MDHCP servers to provide services for scopes in 589 which they do not reside. However, such servers MUST make special 590 efforts to ensure that their services meet clients' needs for largely 591 conflict-free allocation and accurate scope list information. In 592 particular, AAP traffic does not extend outside of the scope that is 593 being managed so coordinating with other servers may be difficult. 594 Also, establishing which scope the client is in may be difficult. If 595 an MDHCP server is not prepared to provide services for scopes in 596 which it does not reside, it SHOULD ignore requests whose scope does 597 not match (or is enclosed by) the scope of the MDHCP Server Multicast 598 Address on which the request was received. 600 2.10. Clock Skew 602 The Current Time option is used to detect and handle clock skew 603 between MDHCP clients and servers. This option SHOULD be included in 604 any MDHCP message that includes an absolute time (such as the Start 605 Time option). It MAY be included in any MDHCPDISCOVER, MDHCPOFFER, 606 MDHCPREQUEST, or MDHCPACK message. 608 Clock skew is a situation where two systems have clocks that are not 609 synchronized. MDHCP servers SHOULD expect and tolerate a small amount 610 of clock skew with their clients (such as an hour) by ensuring that 611 multicast addresses are allocated for an extra hour or so on either 612 side of the lease given to the client. However, large amounts of 613 clock skew require special handling. 615 The Current Time option contains the sender's opinion of the current 616 time in UTC at or about the time the message was assembled. Because 617 of delays in transmission and processing, this value will rarely 618 match the receiver's opinion of the current time at the time the 619 option is processed by the receiver. 621 If an MDHCP server detects substantial clock skew, it SHOULD ignore 622 the client. The server MAY log a message. 624 2.11. Using MDHCP Without Administrative Scoping 625 MDHCP can be used in an environment that does not have administrative 626 scoping enabled. In such an environment, TTL scoping SHOULD be used. 627 The Multicast Scope List option MAY be used to distribute information 628 about TTL scopes that are enforced with TTL thresholds. MDHCP clients 629 MAY include the Multicast TTL option in MDHCPDISCOVER or MDHCPREQUEST 630 packets. MDHCP servers MUST include the Multicast TTL option in 631 MDHCPOFFER and MDHCPACK packets when the TTL to be used is less than 632 255. 634 Multicast MDHCPDISCOVER, MDHCPREQUEST, and MDHCPINFORM packets must 635 be carefully managed in a TTL scoped environment to avoid flooding 636 them around the world. MDHCP clients MAY be configured (manually or 637 via DHCP) with an MDHCP Server Multicast Address and appropriate TTL. 638 Alternatively, the MDHCP Server Multicast Addresses associated with 639 the IPv4 Local Scope or IPv4 Allocation Scope may be blocked so that 640 packets sent to them with TTL of 16 are not sent outside a certain 641 boundary. In this case, MDHCP clients need not be configured manually 642 or via DHCP, since their default behavior in choosing an MDHCP Server 643 Multicast Address without configuration is to choose the MDHCP Server 644 Multicast Address associated with the IPv4 Local Scope and, if this 645 fails, IPv4 Allocation Scope, using TTL no more than 16. 647 3. MDHCP Options 649 The following options are defined for use in MDHCP messages. The 650 options are listed in numerical order. 652 3.1. Pad Option 654 The pad option can be used to cause subsequent fields to align on 655 word boundaries. 657 The code for the pad option is 0, and its length is 1 octet. 659 Code 660 +-----+ 661 | 0 | 662 +-----+ 664 3.2. Requested IP Address 666 This option is used in a client request (MDHCPDISCOVER or 667 MDHCPREQUEST) to allow the client to request that a particular 668 multicast address be assigned. 670 The code for this option is 50, and its length is 4. 672 Code Len Address 673 +-----+-----+-----+-----+-----+-----+ 674 | 50 | 4 | a1 | a2 | a3 | a4 | 675 +-----+-----+-----+-----+-----+-----+ 677 3.3. IP Address Lease Time 679 This option is used in a client request (MDHCPDISCOVER or 680 MDHCPREQUEST) to allow the client to request a lease time for the 681 multicast address. In a server reply (MDHCPOFFER), an MDHCP server 682 uses this option to specify the lease time it is willing to offer. 684 The time is in units of seconds, and is specified as a 32-bit 685 unsigned integer. 687 The code for this option is 51, and its length is 4. 689 Code Len Lease Time 690 +-----+-----+-----+-----+-----+-----+ 691 | 51 | 4 | t1 | t2 | t3 | t4 | 692 +-----+-----+-----+-----+-----+-----+ 694 3.4. MDHCP Message Type 696 This option is used to convey the type of the MDHCP message. The 697 code for this option is 53, and its length is 1. Legal values for 698 this option are: 700 Value Message Type 701 ----- ------------ 702 1 MDHCPDISCOVER 703 2 MDHCPOFFER 704 3 MDHCPREQUEST 705 4 reserved 706 5 MDHCPACK 707 6 MDHCPNAK 708 7 MDHCPRELEASE 709 8 MDHCPINFORM 711 Code Len Type 712 +-----+-----+-----+ 713 | 53 | 1 | 1-8 | 714 +-----+-----+-----+ 716 3.5. Server Identifier 718 This option is used in MDHCPOFFER and MDHCPREQUEST messages, and may 719 optionally be included in the MDHCPACK and MDHCPNAK messages. MDHCP 720 servers include this option in the MDHCPOFFER in order to allow the 721 client to distinguish between lease offers. MDHCP clients use the 722 contents of the 'server identifier' field as the destination address 723 for any MDHCP messages unicast to the MDHCP server. MDHCP clients 724 also indicate which of several lease offers is being accepted by 725 including this option in an MDHCPREQUEST message. 727 The identifier is the IP address of the selected server. 729 The code for this option is 54, and its length is 4. 731 Code Len Address 732 +-----+-----+-----+-----+-----+-----+ 733 | 54 | 4 | a1 | a2 | a3 | a4 | 734 +-----+-----+-----+-----+-----+-----+ 736 3.6. Client Identifier 738 This option is used by MDHCP clients to specify their unique 739 identifier. MDHCP servers use this value to index their database of 740 address bindings. This value is expected to be unique for all 741 clients in an administrative domain. 743 Identifiers SHOULD be treated as opaque objects by MDHCP servers. 745 The client identifier MAY consist of type-value pairs similar to the 746 of a hardware type and hardware address. In this case the type field 747 SHOULD be one of the ARP hardware types defined in STD2 [8]. A 748 hardware type of 0 (zero) should be used when the value field 749 contains an identifier other than a hardware address (e.g. a fully 750 qualified domain name). 752 For correct identification of clients, each client's client- 753 identifier MUST be unique among the client-identifiers used on the 754 subnet to which the client is attached. Vendors and system 755 administrators are responsible for choosing client-identifiers that 756 meet this requirement for uniqueness. 758 The code for this option is 61, and its minimum length is 2. 760 Code Len Type Client-Identifier 761 +-----+-----+-----+-----+-----+--- 762 | 61 | n | t1 | i1 | i2 | ... 763 +-----+-----+-----+-----+-----+--- 765 3.7. Multicast Scope 767 The multicast scope option is used by the client to indicate the 768 multicast scope for the requested multicast address. It is also used 769 to indicate the scope of the assigned address by the MDHCP server. If 770 this option is not specified, the MDHCP server MAY allocate an 771 address from a default scope or reject the request. 773 Code Len Scope ID 774 +-----+-----+-----+-----+-----+-----+ 775 | 101 | 4 | i1 | i2 | i3 | i4 | 776 +-----+-----+-----+-----+-----+-----+ 778 The client may obtain the scope list through the Multicast Scope List 779 option or using some other means. The scope id is the first multicast 780 address in the scope. 782 The code for this option is 101 and the length is 4. 784 3.8. Start Time 786 The Start Time option is used in a client request (MDHCPDISCOVER or 787 MDHCPREQUEST) to allow the client to request the starting time for 788 the use of the assigned address. This option allows a client to 789 request a multicast address for use at a future time. 791 Code Len Time 792 +-----+-----+-----+-----+-----+-----+ 793 | 102 | 4 | t1 | t2 | t3 | t4 | 794 +-----+-----+-----+-----+-----+-----+ 796 The time value is an unsigned 32 bit integer in network byte order 797 giving the number of seconds since 00:00 UTC, 1st January 1970. This 798 is consistent with the time format used in AAP [9] and can be 799 converted to an NTP timestamp by adding decimal 2208988800. This time 800 format will not wrap until the year 2106. 802 If the Start Time option is present, the IP Address Lease Time option 803 specifies the duration of the lease beginning at the Start Time 804 option value. 806 If the Start Time option is present, the Current Time option MUST 807 also be present, as described in section 2.10. 809 The code for this option is 102 and the length is 4. 811 3.9. Multicast TTL 813 This option specifies the TTL value to be used with the multicast 814 address. The TTL is specified as an octet with a value between 1 and 815 255. The implied value of this option is 255 when not included. 817 Code Len Multicast TTL 818 +-----+-----+-----+ 819 | 103 | 1 | n | 820 +-----+-----+-----+ 822 The code for this option is 103 and the length is 1. 824 3.10. Number of Addresses Requested 826 This option specifies the minimum and desired number of addresses 827 requested by the client. These values are unsigned 16 bit integers 828 stored in network byte order. The minimum MUST be less than or equal 829 to the desired number. If a packet is received where this is not the 830 case, the desired value MUST be used for both. 832 The client MAY obtain more than one address either by repeating the 833 protocol for every address or by requesting several addresses at the 834 same time via this option. When the client is requesting only one 835 address, this option SHOULD not be included. An MDHCP server 836 receiving an MDHCPDISCOVER or MDHCPREQUEST packet including this 837 option MUST include between minimum and desired number of addresses 838 in any MDHCPOFFER or MDHCPACK response. 840 The server MAY use this option to indicate to the client the number 841 of addresses it has allocated to the client. In this case, the 842 minimum and desired values MUST be equal. 844 Code Len Minimum Desired 845 +-----+-----+-----+-----+-----+-----+ 846 | 104 | 4 | min | desired | 847 +-----+-----+-----+-----+-----+-----+ 849 The code for this option is 104 and the length is 4. 851 3.11. Requested Language 853 This option specifies the language in which the MDHCP client would 854 like strings such as zone names to be returned. It is an RFC 1766 855 [11] language tag. The proper way to handle this tag with respect to 856 zone names is discussed further in the definition of the Multicast 857 Scope List option. 859 Code Len Language Tag 860 +-----+-----+-----+-...-+-----+ 861 | 110 | n | L1 | | Ln | 862 +-----+-----+-----+-...-+-----+ 864 The code for this option is 110. 866 3.11. Multicast Scope List 868 The format of the multicast scope list option is: 870 Code Len Count Scope List 871 +-----+-----+-----+-----+-...-+-----+ 872 | 107 | p | m | L1 | | Lm | 873 +-----+-----+-----+-----+-...-+-----+ 875 The scope list is a list of m tuples, where each tuple is of the 876 form, 878 Scope ID ( 4 Bytes ) Last Address (4 Bytes ) 879 +-----+-----+-----+-----+-----+-----+-----+-----+ 880 | ID1 | ID2 | ID3 | ID4 | E1 | E2 | E3 | E4 | 881 +-----+-----+-----+-----+-----+-----+-----+-----+ 883 TTL Name Encoded Name List 884 Count 885 +-----+-----+-----+-...-+-----+ 886 | T | n | EN1 | | ENn | 887 +-----+-----+-----+-...-+-----+ 889 where Scope ID is the first multicast address in the scope, Last 890 Address is the last multicast address in the scope, TTL is the 891 multicast TTL value for the multicast addresses of the scope, and 892 Name Count is the number of encoded names for this zone (which may be 893 zero). Each encoded name is of the form 895 Name Lang Language Tag Name Name 896 Flags Length Length 897 +-----+-----+-----+-...-+-----+-----+-----+-...-+-----+ 898 | F | q | L1 | | Lq | r | N1 | | Nr | 899 +-----+-----+-----+-...-+-----+-----+-----+-...-+-----+ 901 where Name Flags is a flags field with flags defined below, Lang 902 Length is the length of the Language Tag in octets (which may be 903 zero), Language Tag is a language tag indicating the language of the 904 zone name (as described in [11]), Name Length is the length of the 905 Name in octets, and Name is a UTF-8 [10] string indicating the name 906 given to the scope zone. 908 The high bit of the Name Flags field is set if the following name 909 should be used if no name is available in a desired language. 910 Otherwise, this bit is cleared. All remaining bits in the octet 911 SHOULD be set to zero and MUST be ignored. 913 The scope IDs of entries in the list SHOULD be unique and the scopes 914 SHOULD be listed from smallest to largest. 916 If the client has not specified a Requested Language option in its 917 request, the MDHCP server SHOULD return all zone names for each zone. 918 If the client has specified a Requested Language option in its 919 request, the MDHCP server MUST return no more than one zone name for 920 each zone. For each zone, the MDHCP server SHOULD first look for a 921 zone name that matches the requested language tag (using a case- 922 insensitive ASCII comparison). If any names match, one of them should 923 be returned. Otherwise, the MDHCP server SHOULD choose another zone 924 name to return (if any are defined). It SHOULD give preference to 925 zone names that are marked to be used if no name is available in a 926 desired language. 928 If the scope list is too long to fit into a single Multicast Scope 929 List option (255 bytes), the server SHOULD split it at 255 bytes and 930 place the remaining bytes in one or more subsequent Multicast Scope 931 List options. The client SHOULD carefully scan the entire set of 932 options and reassemble the scope list by concatenating all Multicast 933 Scope List options before attempting to parse them. 935 The code for this option is 107. 937 Example: 939 There are two scopes supported by the multicast address allocation 940 server: Inside abcd.com with addresses 239.192.0.0-239.195.255.255, 941 and world with addresses 224.0.1.0-238.255.255.255. Then this option 942 will be given as: 944 Code Len Count 945 +-----+-----+-----+... 946 | 107 | 51 | 2 | 947 +-----+-----+-----+... 949 Scope ID Last Address TTL Name Name Lang Language 950 Count Flags Length Tag 951 +---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+... 952 |239|192| 0 | 0 |239|195|255|255|10 | 1 | 128 | 2 | en | 953 +---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+... 955 Name 956 Length Name 957 +------+--+--+-...-+--+--+... 958 | 15 | Inside abcd.com | 959 +------+--+--+-...-+--+--+... 961 Scope ID Last Address TTL Name Name Lang Language 962 Count Flags Length Tag 963 +---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+... 964 |224| 0 | 1 | 0 |238|255|255|255|16 | 1 | 128 | 2 | en | 965 +---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+... 967 Name 968 Length Name 969 +------+--...--+ 970 | 5 | world | 971 +------+--...--+ 973 3.12. List of Address Ranges Allocated 975 This option is used by the server to provide the list of all the 976 address ranges allocated to the client when the client requests more 977 than one address. When a client requests only one address, the server 978 uses the 'yiaddr' field to specify the allocated address. When a 979 client requests more than one address, additional address ranges are 980 listed via this option. 982 This option is also used by the client when requesting a lease 983 extension for more than one address or releasing more than one 984 address. 986 Code Len Address Range List 987 +-----+-----+-----+-----+-...-+-----+ 988 | 108 | n | L1 | L2 | | Ln | 989 +-----+-----+-----+-----+-----+-----+ 990 where the Address Range List is of the following format. 992 StartAddress1 BlockSize1 StartAddress2 BlockSize2 ... 993 +---+---+---+---+---+---+---+---+---+---+---+---+--...--+ 994 |S11|S12|S13|S14|B11|B12|S21|S22|S23|S24|B21|B22| | 995 +---+---+---+---+---+---+---+---+---+---+---+---+-------+ 997 The code for this option is 108 and the minimum length is 6. 999 3.13. Current Time 1001 The current time may be used to express what the sender thinks the 1002 current time is. This option may be used to detect clock skew and 1003 MUST be used if the Start Time option is used, as described in 1004 section 2.10. 1006 Code Len Time 1007 +-----+-----+-----+-----+-----+-----+ 1008 | 109 | 4 | t1 | t2 | t3 | t4 | 1009 +-----+-----+-----+-----+-----+-----+ 1011 The time value is an unsigned 32 bit integer in network byte order 1012 giving the number of seconds since 00:00 UTC, 1st January 1970. This 1013 is consistent with the time format used in AAP [9] and can be 1014 converted to an NTP [4] timestamp by adding decimal 2208988800. This 1015 time format will not wrap until the year 2106. 1017 The code for this option is 109 and the length is 4. 1019 3.14. End Option 1021 The end option marks the end of valid information in the vendor 1022 field. Subsequent octets should be filled with pad options. 1024 The code for this option is 255, and the length is 1. 1026 Code 1027 +-----+ 1028 | 255 | 1029 +-----+ 1031 4. Open Issues and Action Items 1033 We refer to Allocation Scope, but this has not been assigned by IANA 1034 yet. If this is still the case when we want to go to Proposed 1035 Standard, we will have to remove these references. 1037 5. Security Considerations 1039 There are several security risks associated with multicast address 1040 allocation. 1042 First, multicast addresses are a scarce commodity. Therefore, it may 1043 be desirable or necessary to provide access controls on allocation 1044 services. Enforcing such controls requires client authentication with 1045 replay prevention. 1047 Second, there are many possibilities for denial of service. 1048 Allocating excessive numbers of addresses may be addressed by 1049 providing access controls as described above. Deallocating or 1050 modifying other clients' addresses may be handled in a similar way. 1051 Installing a false server can be addressed by requiring clients to 1052 authenticate servers. 1054 Third, information about who has allocated what may disclose 1055 confidential information and may be useful in other attacks such as 1056 sending extra data to your enemies' multicast groups. Providing 1057 confidentiality via encryption addresses those problems somewhat, 1058 although traffic analysis is still possible. 1060 There are already efforts underway in the DHC Working Group that 1061 should be helpful with these problems. The authors are monitoring 1062 this work and hope to apply the solutions developed there in this 1063 context. 1065 6. Acknowledgments 1067 The authors would like to thank Rajeev Byrisetty, Steve Deering, 1068 Peter Ford, Mark Handley, Van Jacobson, David Oran, Thomas Pfenning, 1069 Dave Thaler, Ramesh Vyaghrapuri and the participants of the IETF for 1070 their assistance with this protocol. 1072 Much of the text in this document is based on or copied from [1] and 1073 [2]. The authors of this document would like to express their 1074 gratitude to the authors of these previous works. Any errors in this 1075 document are solely the fault of the authors of this document. 1077 7. References 1079 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 1080 March 1997. 1082 [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor 1083 Extensions", RFC 2132, March 1997. 1085 [3] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, 1086 July 1998. 1088 [4] Mills, D., "Network Time Protocol (Version 3) Specification, 1089 Implementation and Analysis", RFC 1305, March 1992. 1091 [5] Handley, M., D. Thaler, and D. Estrin, "The Internet Multicast 1092 Address Allocation Architecture", Internet Draft, draft-handley- 1093 malloc-arch-00.txt, December 1997. 1095 [6] Handley, M., "Multicast-Scope Zone Announcement Protocol 1096 (MZAP)", Internet Draft, draft-ietf-mboned-mzap-00.txt, December 1097 1997. 1099 [7] Croft, W., and J. Gilmore, "Bootstrap Protocol", RFC 951, 1100 Stanford University and Sun Microsystems, September 1985. 1102 [8] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1103 1700, USC/Information Sciences Institute, July 1992. 1105 [9] Handley, M., "Multicast Address Allocation Protocol (AAP)", 1106 Internet Draft, draft-handley-aap-00.txt, December 1997. 1108 [10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1109 2279, January 1998. 1111 [11] Alvestrand, H., "Tags for the Identification of Languages", RFC 1112 1766, March 1995. 1114 8. Authors' Addresses 1116 Baiju V. Patel 1117 Intel Corp. 1118 2111 NE 25th Ave. 1119 Hillsboro, OR 97124 1121 Phone: 503 264 2422 1122 EMail: baiju.v.patel@intel.com 1124 Munil Shah 1125 Microsoft Corporation 1126 One Microsoft Way 1127 Redmond, WA 98052 1129 Phone: 425 703 3924 1130 Email: munils@microsoft.com 1132 Stephen R. Hanna 1133 Sun Microsystems, Inc. 1134 2 Elizabeth Drive, M/S UCHL03-205 1135 Chelmsford, MA 01824 1137 Phone: +1.978.442.0166 1138 Email: steve.hanna@sun.com 1140 APPENDIX A: Examples 1142 This appendix includes several examples of typical MDHCP protocol 1143 exchanges. 1145 1. Unicast Address Allocation 1147 In this example, an MDHCP client wants to allocate a multicast 1148 address from the global scope for use during the next two hours. It 1149 knows (through prior configuration or communication) the scopes that 1150 are in effect at its location and the unicast address of an MDHCP 1151 server that provides allocation services for the global scope. 1153 The client begins by unicasting an MDHCPREQUEST packet to the server. 1154 This packet includes the IP Address Lease Time, MDHCP Message Type, 1155 Client Identifier, and Multicast Scope options. 1157 The server responds with an MDHCPACK packet containing the requested 1158 address. The address is stored in the yiaddr field. This packet 1159 includes the IP Address Lease Time, MDHCP Message Type, Client 1160 Identifier, and Multicast Scope options. 1162 At this time, the client is said to have a two hour "lease" on the 1163 multicast address, indicating that (with high likelihood) this 1164 address will not be allocated to any other clients in the same scope 1165 for use during this period. The client may then proceed to distribute 1166 the address to others and conduct a multicast session on the address. 1168 If the client had not received a response from the server, it would 1169 probably have retransmitted its MDHCPREQUEST packet for a while. If 1170 it still received no response, it could try another server or move to 1171 multicast discovery with the MDHCPDISCOVER message. 1173 The following figure illustrates this exchange. 1175 Client Server 1176 v v 1177 | | 1178 |\_____________ | 1179 | MDHCPREQUEST \| 1180 | | 1181 | Commits address 1182 | | 1183 | _____________/| 1184 |/ MDHCPACK | 1185 | | 1186 | | 1187 v v 1189 Figure 2: Timeline diagram of messages exchanged 1190 in Unicast Address Allocation example 1192 2. Lease Extension 1194 This is a continuation of the previous example. The client has 1195 already allocated a multicast address from the global scope for use 1196 during the next two hours. Half way through this two hour period, it 1197 decides that it wants to extend its lease for another hour. 1199 The client unicasts an MDHCPREQUEST packet to the server from which 1200 it allocated the address. This packet includes the Requested IP 1201 Address, IP Address Lease Time, MDHCP Message Type, and Client 1202 Identifier options. The time included in the IP Address Lease Time is 1203 two hours, since the client wants the lease to expire two hours from 1204 the current time. 1206 The server responds with an MDHCPACK packet indicating that the lease 1207 extension has been granted. The address is stored in the yiaddr 1208 field. This packet includes the IP Address Lease Time, MDHCP Message 1209 Type, Client Identifier, and Multicast Scope options. 1211 If the server did not want to grant the requested lease extension, it 1212 would have responded with an MDHCPACK packet with the remaining lease 1213 time indicated in the IP Address Lease Time option. It would *not* 1214 send an MDHCPNAK packet, since that would cancel the lease 1215 immediately. 1217 The following figure illustrates this exchange. 1219 Client Server 1220 v v 1221 | | 1222 |\_____________ | 1223 | MDHCPREQUEST \| 1224 | | 1225 | Extends lease 1226 | | 1227 | _____________/| 1228 |/ MDHCPACK | 1229 | | 1230 | | 1231 v v 1233 Figure 3: Timeline diagram of messages exchanged 1234 in Lease Extension example 1236 3. Address Release 1238 This is a continuation of the previous example. The client has 1239 already allocated a multicast address and extended its lease for 1240 another two hours. Half an hour later, the client finishes its use of 1241 the multicast address and wants to release it so it can be reused. 1243 The client unicasts an MDHCPRELEASE packet to the server from which 1244 it allocated the address. This packet includes the Requested IP 1245 Address, MDHCP Message Type, and Client Identifier options. When the 1246 server receives this packet, it cancels the client's lease on the 1247 address. 1249 Since the server does not acknowledge the MDHCPRELEASE packet, there 1250 is no provision for the client retransmitting it. However, this is 1251 not very harmful. If an MDHCPRELEASE packet is lost, the server will 1252 keep the multicast address reserved for the client's use until the 1253 end of its lease. At that point, the address will once again be 1254 available for use by others. 1256 The following figure illustrates this exchange. 1258 Client Server 1259 v v 1260 | | 1261 |\_____________ | 1262 | MDHCPRELEASE \| 1263 | | 1264 | Cancels lease 1265 | | 1266 v v 1268 Figure 4: Timeline diagram of messages exchanged 1269 in Address Release example 1271 4. Multicast Discovery and Address Allocation 1273 Let's revisit the first example, but say that the MDHCP client did 1274 not know the unicast address of the MDHCP server that it wanted to 1275 use. 1277 The client begins by multicasting an MDHCPDISCOVER packet to an MDHCP 1278 Server Multicast Address. This packet includes the IP Address Lease 1279 Time, MDHCP Message Type, Client Identifier, and Multicast Scope 1280 options. 1282 Any servers that receive the MDHCPDISCOVER packet and can satisfy 1283 this request temporarily reserve an address for the client and 1284 unicast an MDHCPOFFER packet to the client. These packets contain the 1285 IP Address Lease Time, MDHCP Message Type, Server Identifier, Client 1286 Identifier, and Multicast Scope options. The reserved address is also 1287 stored in the yiaddr field. 1289 After a suitable delay, the client multicasts an MDHCPREQUEST packet 1290 to the MDHCP Server Multicast Address. This packet contains all of 1291 the options included in the MDHCPDISCOVER packet, but also includes 1292 the Server Identifier option, indicating which server it has selected 1293 for the request. 1295 The server whose Server Identifier matches the one specified by the 1296 client responds with an MDHCPACK packet containing the same 1297 information as the MDHCPOFFER packet. All the other servers that had 1298 sent MDHCPOFFER packets stop reserving an address for the client and 1299 forget about the whole exchange. 1301 The client now has a two hour "lease" on the multicast address, just 1302 like it did in the first example. 1304 If the client had not received a response from the server, it would 1305 have retransmitted its MDHCPREQUEST packet for a while. If it still 1306 received no response, it could try another server or return to 1307 multicast discovery with a new MDHCPDISCOVER message. 1309 The following figure illustrates this exchange. 1311 Server Client Server 1312 (not selected) (selected) 1313 v v v 1314 | | | 1315 |Begin multicast address request| 1316 | | | 1317 | _____________/|\_____________ | 1318 |/MDHCPDISCOVER | MDHCPDISCOVER\| 1319 | | | 1320 Reserves | Reserves 1321 Address | Address 1322 | | | 1323 |\ | ____________/| 1324 | \_________ | /MDHCPOFFER | 1325 | MDHCPOFFER\ |/ | 1326 | \ | | 1327 | Collects replies | 1328 | \| | 1329 | Selects Address | 1330 | | | 1331 | _____________/|\_____________ | 1332 |/ MDHCPREQUEST | MDHCPREQUEST \| 1333 | | | 1334 | | Commits address 1335 | | | 1336 | | _____________/| 1337 | |/ MDHCPACK | 1338 | | | 1339 | assignment complete | 1340 | | | 1341 v v v 1343 Figure 5: Timeline diagram of messages exchanged 1344 in Multicast Discovery and Address Allocation example 1346 APPENDIX B: Change Log 1348 CHANGES FROM draft-ietf-malloc-mdhcp-00.txt 1350 Port number assigned. 1352 Removed unused chaddr, sname, and file fields. 1354 Split MDHCP option space from DHCP. 1356 Changed technique for choosing MDHCP Server Multicast Addresses when 1357 initial requests fail. 1359 Added Requested Language option. 1361 Added language tags and multiple names per zone to the Multicast 1362 Scope List option. 1364 CHANGES FROM draft-ietf-dhc-mdhcp-03.txt 1366 Many changes to make this document no longer dependent on the DHCP 1367 spec. This should make the document easier to read and understand. 1369 Removed MDHCPDECLINE. 1371 Added Current Time option to deal with clock skew. 1373 Scopes are now identified by the first multicast address in the scope 1374 instead of using a scope ID. 1376 Changed Total Addresses Requested option to Number of Addresses 1377 Requested. Changed this option to have minimum and desired fields. 1379 Clarified that servers MAY send MDHCPOFFER or MDHCPACK messages with 1380 shorter lifetimes or later start times than those requested by the 1381 client. This is consistent with DHCP and provides a simple way to 1382 achieve the minimum/maximum lifetime functionality described in the 1383 malloc abstract API.