idnits 2.17.00 (12 Aug 2021) /tmp/idnits65260/draft-ietf-malloc-madcap-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == 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 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. A MADCAP server receiving a DISCOVER or REQUEST packet including this option MUST include between minimum and desired number of addresses in any OFFER or ACK 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) -- Looks like a reference, but probably isn't: 'DISCOVER-DELAY' on line 366 -- Looks like a reference, but probably isn't: 'OFFER-HOLD' on line 421 -- Looks like a reference, but probably isn't: 'NO-RESPONSE-DELAY' on line 585 ** Obsolete normative reference: RFC 1305 (ref. '4') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2279 (ref. '5') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 1766 (ref. '6') (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2434 (ref. '7') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2401 (ref. '8') (Obsoleted by RFC 4301) Summary: 11 errors (**), 0 flaws (~~), 3 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 February 1999 Stephen R. Hanna, Sun Microsystems, Inc. 5 Expires: August 1999 draft-ietf-malloc-madcap-04.txt 7 Multicast Address Dynamic Client Allocation Protocol (MADCAP) 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document defines a protocol, Multicast Address Dynamic Client 33 Allocation Protocol (MADCAP), that allows hosts to request multicast 34 addresses from multicast address allocation servers. 36 1. Introduction 38 Multicast Address Dynamic Client Allocation Protocol (MADCAP) is a 39 protocol that allows hosts to request multicast address allocation 40 services from multicast address allocation servers. This protocol is 41 part of the Multicast Address Allocation Architecture being defined 42 by the IETF Multicast Address Allocation Working Group. However, it 43 may be used separately from the rest of that architecture as 44 appropriate. 46 1.1. Protocol Overview 48 MADCAP is built on a client-server model, where hosts request address 49 allocation services from address allocation servers. See Appendix A 50 for examples of typical protocol exchanges. 52 1.2. Terminology 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119. 58 Throughout the rest of this document, the words "server" or "MADCAP 59 server" refer to a host providing multicast address allocation 60 services via MADCAP. The words "client" or "MADCAP client" refer to a 61 host requesting multicast address allocation services via MADCAP. 63 1.3. Motivation and Protocol Requirements 65 For multicast applications to be deployed everywhere, there is a need 66 to define a protocol that any host may use to allocate multicast 67 addresses. Here are the requirements for such a protocol. 69 Quick response: The host should be able to allocate a multicast 70 address and begin to use it promptly. 72 Low network load: Hosts that are not allocating or deallocating 73 multicast addresses at the present time should not need to send or 74 receive any network traffic. 76 Support for intermittently connected or power managed systems: Hosts 77 should be able to be disconnected from the network, powered off, or 78 otherwise inaccessible except during the brief period during which 79 they are allocating a multicast address. 81 Multicast address scopes: The protocol must be able to allocate both 82 the administratively scoped and globally scoped multicast addresses. 84 Efficient use of address space: The multicast address space is fairly 85 small. The protocol should make efficient use of this scarce 86 resource. 88 Authentication: Because multicast addresses are scarce, it is 89 important to protect against hoarding of these addresses. One way to 90 do this is by authenticating clients. 92 Policy neutral: Allocation policies (such as who can allocate 93 addresses) should not be dictated by the protocol. 95 1.4. Relationship with DHCP 97 MADCAP was originally based on DHCP. There are still some 98 similarities and it may be possible to share some code between a DHCP 99 implementation and a MADCAP implementation. However, MADCAP is 100 completely separate from DHCP, with no dependencies between the two 101 and many significant differences. 103 2. Protocol Description 105 The MADCAP protocol is a client-server protocol. In general, the 106 client unicasts or multicasts a message to one or more servers, which 107 optionally respond with messages unicast to the client. 109 Messages are always sent via UDP. A reserved port number dedicated 110 for MADCAP is used on the server (port number 2535, as assigned by 111 IANA). Any port number may be used on client machines. When a MADCAP 112 server sends a message to a MADCAP client, it MUST use a destination 113 port number that matches the source port number provided by the 114 client in the message that caused the server to send its message. 116 MADCAP is a mechanism rather than a policy. MADCAP allows local 117 system administrators to exercise control over configuration 118 parameters where desired. For example, MADCAP servers may be 119 configured to limit the number of multicast addresses allocated to a 120 single client. Properly enforcing such a limit requires cryptographic 121 security, as described in the Security Consideration section. 123 All MADCAP messages have the same format. Each message includes a 124 version, a message type, a transaction id, and a type-length-value 125 encoded options field. 127 The next few sections describe the MADCAP message format and message 128 types. A full list of MADCAP options is provided in section 3. 130 2.1. Message Format 132 Figure 1 gives the format of a MADCAP message and Table 1 describes 133 each of the fields in the MADCAP message. The numbers in parentheses 134 indicate the size of each field in octets. The names for the fields 135 given in the figure will be used throughout this document to refer to 136 the fields in MADCAP messages. 138 All multi-octet quantities are in network byte-order. 140 Any message whose UDP data is too short to hold this format (at least 141 12 bytes) MUST be ignored. 143 +-+-+-+-+-+-+-+-+ 144 | version (1) | 145 +---------------+ 146 | msgtype (1) | 147 +---------------+ 148 | addrfamily | 149 | (2) | 150 +---------------+ 151 | | 152 | xid (4) | 153 | | 154 | | 155 +---------------+ 156 | | 157 | options | 158 | (variable) | 159 | ... | 160 +---------------+ 162 Figure 1: Format of a MADCAP message 164 FIELD OCTETS DESCRIPTION 165 ----- ------ ----------- 167 version 1 Protocol version number (zero for this specification) 168 msgtype 1 Message type (DISCOVER, INFORM, etc.) 169 addrfamily 2 Address family (IPv4, IPv6, etc.) 170 xid 4 Transaction ID 171 options var Options field 173 Table 1: Description of fields in a MADCAP message 175 2.1.1. The version field 177 The version field must always be zero for this version of the 178 protocol. Any messages that include other values in this field MUST 179 be ignored. 181 2.1.2. The msgtype field 183 The msgtype field defines the "type" of the MADCAP message. 185 For more information about this field, see section 2.2. 187 2.1.3. The addrfamily field 189 The addrfamily field defines the default address family (such as IPv4 190 or IPv6) for this MADCAP message. Unless otherwise specified, all 191 addresses included in the message will be from this family. The set 192 of address families is defined by the IANA, with IPv4 being 1 and 193 IPv6 being 2. 195 2.1.4. The xid field 197 The xid field is a transaction id. This is a number chosen by the 198 client so that the combination of xid, msgtype, and Client Identifier 199 option value is unique over some short period of time. 201 The xid field is used by the client and server to associate messages 202 and responses between a client and a server. Before a client sends a 203 message, it chooses a number to use as an xid. When the server 204 responds to a client message, it MUST use the same xid value in the 205 response that the client used in the request. This allows the client 206 to associate responses with the message that they are responding to. 208 When retransmitting messages (as described in section 2.3), the 209 client MUST retransmit them without changing them, thereby using the 210 same xid, msgtype, and Client Identifier option. The client SHOULD 211 NOT use the same xid, msgtype, and Client Identifier together for two 212 different messages. 214 If a server receives a message with the same xid value, msgtype 215 value, and Client Identifier option value as one received within 216 [RESPONSE_CACHE_INTERVAL], it SHOULD treat this message as a 217 retransmission of the previously received one and retransmit the 218 response, if any. After [RESPONSE_CACHE_INTERVAL], the server may 219 forget about the previously received message and treat any 220 retransmissions of this message as if they were new messages. 222 This avoids retransmissions causing multiple allocations. An 223 appropriate value for [RESPONSE_CACHE_INTERVAL] would be sixty 224 seconds, but it may have any value (including zero seconds) and may 225 be adjusted dynamically according to resource constraints on the 226 server. 228 2.1.5. The options field 230 The options field consists of a list of tagged parameters that are 231 called "options". All options consist of a two octet option code and 232 a two octet option length, followed by the number of octets specified 233 by the option length. In the case of some options, the length field 234 is a constant but must still be specified. 236 The option field MUST contain any number of options that are not an 237 end option followed by an end option (code 0). Any message whose 238 options field does not conform to this syntax MUST be ignored. 240 Any MADCAP client or server sending a MADCAP message MAY include any 241 of the options listed in section 3, subject to the restrictions in 242 Table 3 and elsewhere in this document. They MAY also include other 243 MADCAP options that are defined in the future. A MADCAP client or 244 server MUST NOT include more than one option with the same option 245 type in one MADCAP message. 247 All MADCAP clients and servers MUST recognize all options listed in 248 this document and behave in accordance with this document when 249 receiving and processing any of these options. Any unrecognized 250 options MUST be ignored. If a message is received that does not 251 conform to the requirements of this document (for instance, not 252 including all required options) it MUST be ignored. The order of 253 options within a message has no significance and any order MUST be 254 supported in an equivalent manner, with the exception that the End 255 option must occur once per message, as the last option in the option 256 field. 258 New MADCAP options may only be defined by IETF Consensus, as 259 described in [7]. Basically, this means that they are defined by RFCs 260 approved by the IESG. 262 2.2. Message Types 264 The msgtype field defines the "type" of a MADCAP message. Legal 265 values for this field are: 267 Value Message Type 268 ----- ------------ 269 1 DISCOVER 270 2 OFFER 271 3 REQUEST 272 4 RENEW 273 5 ACK 274 6 NAK 275 7 RELEASE 276 8 INFORM 278 Table 2: MADCAP message types 280 Throughout this document, MADCAP messages will be referred to by the 281 type of the message; e.g., a MADCAP message with a message type of 0 282 will be referred to as an INFORM message. 284 Here are descriptions of the MADCAP message types. Table 3, which 285 appears at the end of this section, summarizes which options are 286 allowed with each message type. 288 MADCAP clients and servers MUST handle all MADCAP message types 289 defined in this document in a manner consistent with this document. 290 If a client or server receives a message whose message type it does 291 not recognize, it MUST ignore this message. Note, however, that under 292 some circumstances this document requires or suggests that clients or 293 servers ignore certain messages. For instance, clients that do not 294 send DISCOVER messages SHOULD ignore OFFER messages. Also, secure 295 servers SHOULD ignore DISCOVER messages and all servers SHOULD ignore 296 DISCOVER or INFORM messages that they cannot satisfy. 298 New MADCAP message types may only be defined by IETF Consensus, as 299 described in [7]. Basically, this means that they are defined by RFCs 300 approved by the IESG. 302 2.2.1. INFORM 304 The INFORM message is used by a MADCAP client that wants to acquire 305 configuration parameters, especially a multicast scope list. This 306 message also allows a client to determine which servers are likely to 307 be able to handle future requests. 309 The MADCAP client sends out an INFORM message. The message may be 310 unicast to a particular MADCAP server or multicast to a MADCAP Server 311 Multicast Address. For more details about the MADCAP Server Multicast 312 Address, see section 2.9. 314 If a server receives an INFORM message and it can process the request 315 successfully, it SHOULD unicast an ACK message to the client. If the 316 INFORM message includes an Option Request List option, the server 317 SHOULD try to include the specified options in its response, but is 318 not required to do so. If the Option Request List option is not 319 included, the server SHOULD include the Multicast Scope List option. 321 If a server receives an INFORM message and it can not process the 322 request successfully, it SHOULD ignore the INFORM message. 324 If a client sends an INFORM message and does not receive any ACK 325 messages in response after an appropriate delay, the client MAY 326 resend its INFORM message, as described in section 2.3. 328 When a MADCAP client sends an INFORM message, it MAY include the 329 Requested Language option, which specifies which language the client 330 would prefer for the zone names in the Multicast Scope List. The 331 proper way to handle this tag with respect to zone names is discussed 332 in the definition of the Multicast Scope List option. 334 2.2.2. DISCOVER 336 The DISCOVER message is a multicast message sent by a MADCAP client 337 that wants to discover MADCAP servers that can probably satisfy a 338 REQUEST. 340 MADCAP clients are not required to use the DISCOVER message. They 341 MAY employ other methods to find MADCAP servers, such as sending a 342 multicast INFORM message, caching an IP address that worked in the 343 past or obtaining a DNS name or IP address from DHCP or prior 344 configuration. Using the DISCOVER message has the particular 345 advantage that it allows clients to automatically move to another 346 server if one fails. 348 The MADCAP client begins by sending a multicast DISCOVER message to a 349 MADCAP Server Multicast Address. Any servers that wish to assist the 350 client respond by sending a unicast OFFER message to the client. If a 351 server can process the request with a shorter lease time or later 352 start time than the client requested, it SHOULD send an OFFER message 353 with the lease time or start time that it can offer. However, it 354 MUST NOT offer a lease time shorter than the minimum lease time 355 specified by the client or a start time later than the maximum start 356 time specified by the client. 358 For more details about the MADCAP Server Multicast Address, see 359 section 2.9. 361 After a suitable delay [DISCOVER-DELAY], the client MAY select the 362 server it wants to use (if any) and send a multicast REQUEST message 363 identifying that server. See section 2.2.4 for more information about 364 the REQUEST message. 366 The value of [DISCOVER-DELAY] and the mechanism used by the client in 367 selecting the server it wants to use are implementation dependent. 369 When a MADCAP client sends a DISCOVER message, it MAY include the 370 Lease Time, Minimum Lease Time, Start Time, Maximum Start Time, 371 Number of Addresses Requested, and List of Address Ranges options, 372 describing the addresses it wants to receive. However, it need not 373 include any of these options. If one of these options is not 374 included, the server will provide the appropriate default (maximum 375 available for Lease Time, no minimum for Minimum Lease Time, as soon 376 as possible for Start Time, no maximum for Maximum Start Time, one 377 for Number of Addresses Requested, and any addresses available for 378 List of Address Ranges). The Multicast Scope option MUST be included 379 in the DISCOVER message so that the server knows what scope should be 380 used. The Current Time option MUST be included if the Start Time or 381 Maximum Start Time options are included. 383 If a client sends a DISCOVER message and does not receive any OFFER 384 messages after an appropriate delay, the client MAY retransmit its 385 DISCOVER message, as described in section 2.3. 387 2.2.3. OFFER 389 The OFFER message is a unicast message sent by a MADCAP server in 390 response to a DISCOVER message that it can probably satisfy. 392 A MADCAP server is never required to send an OFFER message in 393 response to a DISCOVER message. For instance, it may not be able to 394 satisfy the client's request or it may have been configured to 395 respond only to certain types of DISCOVER messages or not to respond 396 to DISCOVER messages at all. 398 If a MADCAP server decides to send an OFFER message, it MUST include 399 the Lease Time and Multicast Scope options, describing the addresses 400 it is willing to provide. However, it need not include the List of 401 Address Ranges option. If the List of Address Ranges Allocated option 402 is not included, it is assumed that the server is willing to provide 403 the number of addresses that the client requested. If the Start Time 404 option is not included, it is assumed that the server is willing to 405 provide the start time requested by the client (if any). The Current 406 Time option MUST be included if the Start Time option is included. 408 If a server can process the request with a shorter lease time or 409 later start time than the client requested, it SHOULD send an OFFER 410 message with the lease time or start time that it can offer. 411 However, it MUST NOT offer a lease time shorter than the minimum 412 lease time specified by the client or a start time later than the 413 maximum start time specified by the client. 415 If the server sends an OFFER message, it SHOULD attempt to hold 416 enough addresses to complete the transaction. If it receives a 417 multicast REQUEST message with the same xid and Client Identifier 418 option as the DISCOVER message for which it is holding these 419 addresses and a Server Identifier option that does not match its own, 420 it SHOULD stop holding the addresses. The server SHOULD also stop 421 holding the addresses after an appropriate delay [OFFER-HOLD] if the 422 transaction is not completed. The value of this delay is 423 implementation-specific. 425 As with all messages sent by the server, the xid field MUST match the 426 xid field included in the client request to which this message is 427 responding. The Client Identifier option MUST be included, with the 428 value matching the one included in the client request. The Server 429 Identifier option MUST be included, with the value being the server's 430 IP address. And the packet MUST NOT be retransmitted. 432 2.2.4. REQUEST 434 The REQUEST message is used by a MADCAP client that wants to allocate 435 one or more multicast addresses. It is not used for renewing an 436 existing lease. The RENEW message is used for that. 438 If a REQUEST message is completing a transaction initiated by a 439 DISCOVER message, the following procedure MUST be followed so that 440 all MADCAP servers know which server was selected. The same xid value 441 used in the DISCOVER message MUST be used in the REQUEST message. 442 Also, the Server Identifier option MUST be included, using the Server 443 Identifier of the server selected. Also, the REQUEST message MUST be 444 multicast to the MADCAP Server Multicast Address. 446 If a REQUEST message is not completing a transaction initiated by a 447 DISCOVER message, the REQUEST message MUST be unicast to the MADCAP 448 server that the client wants to use. In this case, the Server 449 Identifier option MAY be included, but need not be. 451 If the selected server can process the request successfully, it 452 SHOULD unicast an ACK message to the client. Otherwise, it SHOULD 453 unicast an NAK to the client. If a server can process the request 454 with a shorter lease time or later start time than the client 455 requested, it SHOULD send an ACK message with the lease time or start 456 time that it can offer. However, it MUST NOT offer a lease time 457 shorter than the minimum lease time specified by the client or a 458 start time later than the maximum start time specified by the client. 460 When a MADCAP client sends a REQUEST message, it MAY include the 461 Lease Time, Minimum Lease Time, Start Time, Maximum Start Time, 462 Number of Addresses Requested, and List of Address Ranges options, 463 describing the addresses it wants to receive. However, it need not 464 include any of these options. If one of these options is not 465 included, the server will provide the appropriate default (maximum 466 available for Lease Time, no minimum for Minimum Lease Time, as soon 467 as possible for Start Time, no maximum for Maximum Start Time, one 468 for Number of Addresses Requested, and any addresses available for 469 List of Address Ranges). The Multicast Scope option MUST be included 470 in the REQUEST message so that the server knows what scope should be 471 used. The Current Time option MUST be included if the Start Time or 472 Maximum Start Time options are included. 474 If a client sends a REQUEST message and does not receive any ACK or 475 NAK messages in response after an appropriate delay, the client MAY 476 resend its REQUEST message, as described in section 2.3. 478 If the server responds with a NAK or fails to respond within a 479 reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the 480 client MAY try to find another server by sending a DISCOVER message 481 with another xid or sending a REQUEST message with another xid to 482 another server. 484 2.2.5. ACK 486 The ACK message is used by a MADCAP server to respond affirmatively 487 to an INFORM, REQUEST, or RELEASE message. The server unicasts the 488 ACK message to the client from which it received the message to which 489 it is responding. 491 The set of options included with an ACK message differs, depending on 492 what sort of message it is responding to. 494 If the ACK message is responding to an INFORM message, it SHOULD 495 include any options requested by the client using the Option Request 496 List option in the INFORM message. If the Option Request List option 497 was not included in the INFORM message, the server SHOULD include the 498 Multicast Scope List option. 500 If the ACK message is responding to a REQUEST message, it MUST 501 include Lease Time, Multicast Scope, and List of Address Ranges 502 options. It MAY include a Start Time option. If a Start Time option 503 is included, a Current Time option MUST also be included. If no Start 504 Time option is included, the lease is assumed to start immediately. 506 If the ACK message is responding to a RENEW message, it MUST include 507 Lease Time, Multicast Scope, and List of Address Ranges options. It 508 MAY include a Start Time option. If a Start Time option is included, 509 a Current Time option MUST also be included. If no Start Time option 510 is included, the lease is assumed to start immediately. 512 If the ACK message is responding to a RELEASE message, it MUST only 513 include Server Identifier and Client Identifier options. 515 As with all messages sent by the server, the xid field MUST match the 516 xid field included in the client request to which this message is 517 responding. The Client Identifier option MUST be included, with the 518 value matching the one included in the client request. The Server 519 Identifier option MUST be included, with the value being the server's 520 IP address. And the packet MUST NOT be retransmitted. 522 2.2.6. NAK 524 The NAK message is used by a MADCAP server to respond negatively to a 525 REQUEST, RELEASE, or RENEW message. The server unicasts the NAK 526 message to the client from which it received the message to which it 527 is responding. 529 As with all messages sent by the server, the xid field MUST match the 530 xid field included in the client request to which this message is 531 responding. The Client Identifier option MUST be included, with the 532 value matching the one included in the client request. The Server 533 Identifier option MUST be included, with the value being the server's 534 IP address. And the packet MUST NOT be retransmitted. 536 2.2.7. RELEASE 538 The RELEASE message is used by a MADCAP client that wants to 539 deallocate one or more multicast addresses before their lease 540 expires. 542 The client unicasts the RELEASE message to the MADCAP server from 543 which it allocated the addresses. If the selected server can process 544 the request successfully, it SHOULD unicast an ACK message to the 545 client. Otherwise, it SHOULD unicast a NAK to the client. 547 The lease to be released is whichever one was allocated with a Client 548 Identifier option matching the one provided in the RELEASE message. 549 It is not possible to release only part of the addresses in a single 550 lease. 552 If a client sends a RELEASE message and does not receive any ACK or 553 NAK messages in response after an appropriate delay, the client MAY 554 resend its RELEASE message, as described in section 2.3. 556 If the server responds with a NAK or fails to respond within a 557 reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the 558 client MAY send a RELEASE message with another xid to another server, 559 provided that the Server Mobility feature was used in the original 560 REQUEST message and that this feature is required for the subsequent 561 RELEASE message sent to another server. For more information about 562 the Server Mobility feature, see section 2.12.1. 564 2.2.8. RENEW 566 The RENEW message is used by a MADCAP client that wants to renew a 567 multicast address lease, changing the lease time or start time. 569 The client unicasts the RENEW message to a MADCAP server. If the 570 server can process the request successfully, it SHOULD unicast an ACK 571 message to the client. Otherwise, it SHOULD unicast a NAK to the 572 client. 574 The lease to be renewed is whichever one was allocated with a Client 575 Identifier option matching the one provided in the RENEW message. 576 The Lease Time, Start Time, and Current Time options MAY be included, 577 depending on whether the client wishes to change the lease time, the 578 start time, or both. 580 If a client sends a RENEW message and does not receive any ACK or NAK 581 messages in response after an appropriate delay, the client MAY 582 resend its RENEW message, as described in section 2.3. 584 If the server responds with a NAK or fails to respond within a 585 reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the 586 client MAY send a RENEW message with another xid to another server, 587 provided that the Server Mobility feature was used in the original 588 REQUEST message and that this feature is required for the subsequent 589 RENEW message sent to another server. For more information about the 590 Server Mobility feature, see section 2.12.1. 592 2.2.9. Options Allowed 594 Table 3 summarizes which options are allowed with each message type. 596 Option INFORM ACK (in response to INFORM) 597 ------ ------ --------------------------- 598 Lease Time MUST NOT MUST NOT 599 Server Identifier MUST NOT MUST 600 Client Identifier MUST MUST 601 Multicast Scope MUST NOT MUST NOT 602 Option Request List MAY MUST NOT 603 Start Time MUST NOT MUST NOT 604 Number of Addresses 605 Requested MUST NOT MUST NOT 606 Requested Language MAY MUST NOT 607 Multicast Scope List MUST NOT MAY 608 List of Address Ranges MUST NOT MUST NOT 609 Current Time MUST NOT MAY 610 Feature List MAY MAY 611 Retry Time MUST NOT MUST NOT 612 Minimum Lease Time MUST NOT MUST NOT 613 Maximum Start Time MUST NOT MUST NOT 615 Option DISCOVER OFFER 616 ------ -------- ----- 617 Lease Time MAY MUST 618 Server Identifier MUST NOT MUST 619 Client Identifier MUST MUST 620 Multicast Scope MUST MUST 621 Option Request List MUST NOT MUST NOT 622 Start Time MAY MAY 623 Number of Addresses 624 Requested MAY MUST NOT 626 Requested Language MUST NOT MUST NOT 627 Multicast Scope List MUST NOT MUST NOT 628 List of Address Ranges MAY MAY 629 Current Time MAY MAY 630 Feature List MAY MAY 631 Retry Time MUST NOT MUST NOT 632 Minimum Lease Time MAY MUST NOT 633 Maximum Start Time MAY MUST NOT 635 Option REQUEST ACK (in response to REQUEST) 636 ------ ------- ---------------------------- 637 Lease Time MAY MUST 638 Server Identifier MUST (if MUST 639 multicast) 640 Client Identifier MUST MUST 641 Multicast Scope MUST MUST 642 Option Request List MUST NOT MUST NOT 643 Start Time MAY MAY 644 Number of Addresses 645 Requested MAY MUST NOT 646 Requested Language MUST NOT MUST NOT 647 Multicast Scope List MUST NOT MUST NOT 648 List of Address Ranges MAY MUST 649 Current Time MAY MAY 650 Feature List MAY MAY 651 Retry Time MUST NOT MAY 652 Minimum Lease Time MAY MUST NOT 653 Maximum Start Time MAY MUST NOT 655 Option RENEW ACK (in response to RENEW) 656 ------ ----- -------------------------- 657 Lease Time MAY MUST 658 Server Identifier MUST NOT MUST 659 Client Identifier MUST MUST 660 Multicast Scope MUST NOT MUST 661 Option Request List MUST NOT MUST NOT 662 Start Time MAY MAY 663 Number of Addresses 664 Requested MUST NOT MUST NOT 665 Requested Language MUST NOT MUST NOT 666 Multicast Scope List MUST NOT MUST NOT 667 List of Address Ranges MUST NOT MUST 668 Current Time MAY MAY 669 Feature List MAY MAY 670 Retry Time MUST NOT MAY 671 Minimum Lease Time MAY MUST NOT 672 Maximum Start Time MAY MUST NOT 673 Option RELEASE ACK (in response to RELEASE) 674 ------ ------- ---------------------------- 675 Lease Time MUST NOT MUST NOT 676 Server Identifier MUST NOT MUST 677 Client Identifier MUST MUST 678 Multicast Scope MUST NOT MUST NOT 679 Option Request List MUST NOT MUST NOT 680 Start Time MUST NOT MUST NOT 681 Number of Addresses 682 Requested MUST NOT MUST NOT 683 Requested Language MUST NOT MUST NOT 684 Multicast Scope List MUST NOT MUST NOT 685 List of Address Ranges MUST NOT MUST NOT 686 Current Time MUST NOT MAY 687 Feature List MAY MAY 688 Retry Time MUST NOT MUST NOT 689 Minimum Lease Time MUST NOT MUST NOT 690 Maximum Start Time MUST NOT MUST NOT 692 Option NAK 693 ------ --- 694 Lease Time MUST NOT 695 Server Identifier MUST 696 Client Identifier MUST 697 Multicast Scope MUST NOT 698 Option Request List MUST NOT 699 Start Time MUST NOT 700 Number of Addresses 701 Requested MUST NOT 702 Requested Language MUST NOT 703 Multicast Scope List MUST NOT 704 List of Address Ranges MUST NOT 705 Current Time MUST NOT 706 Feature List MAY 707 Retry Time MUST NOT 708 Minimum Lease Time MUST NOT 709 Maximum Start Time MUST NOT 711 Table 3: Options allowed in MADCAP messages 713 2.3. Retransmission 715 MADCAP clients are responsible for all message retransmission. The 716 client MUST adopt a retransmission strategy that incorporates an 717 exponential backoff algorithm to determine the delay between 718 retransmissions. The delay between retransmissions SHOULD be chosen 719 to allow sufficient time for replies from the server to be delivered 720 based on the characteristics of the internetwork between the client 721 and the server. 723 For example, in a 10Mb/sec Ethernet internetwork, the delay before 724 the first retransmission SHOULD be at least 4 seconds. The delay 725 before the next retransmission SHOULD be at least 8 seconds. The 726 retransmission delay SHOULD be doubled with subsequent 727 retransmissions up to a maximum of 64 seconds. The client MAY provide 728 an indication of retransmission attempts to the user as an indication 729 of the progress of the process. The client MAY halt retransmission at 730 any point. 732 2.4. The Client Identifier 734 The Client Identifier option is included in each message sent by an 735 MADCAP client. Its value is used to identify a particular client and 736 MUST be unique across all clients in a multicast address allocation 737 domain. In addition, for each lease requested by a client, the client 738 must use a different client identifier. This allows the lease to be 739 identified using just the client identifier. 741 The first octet of the client identifier is the client identifier 742 type. If the client identifier type is 0, the remainder of the 743 client identifier is a long random number (such as 128 bits from a 744 decent random number generator). If the client identifier type is 1, 745 the remainder of the client identifier is a two octet IANA-defined 746 address family number, an address from the specified address family, 747 and a client-specific identifier (such as a sequence number or the 748 current time). 750 New MADCAP client identifier types may only be defined by IETF 751 Consensus, as described in [7]. Basically, this means that they are 752 defined by RFCs approved by the IESG. 754 The MADCAP server does not need to parse the client identifier. It 755 SHOULD use the client identifier only as an opaque identifier, which 756 must be unique for each lease. The purpose of defining different 757 client identifier types is to allow MADCAP clients that already have 758 a globally unique address to avoid the possibility of client ID 759 collisions by using this address together with a client-specific 760 identifier. MADCAP clients that do not have a globally unique address 761 SHOULD use client identifier type 0. 763 In addition to associating client and server messages (along with the 764 xid field, as described in the next section), the Client Identifier 765 is used to control who can renew or release a lease. MADCAP servers 766 MUST require that the client identifier used in a RENEW or RELEASE 767 message match the client identifier used in the initial REQUEST 768 message. If not, the server MUST ignore the message. To provide true 769 security with this technique, the confidentiality of the client 770 identifier must be maintained by encrypting all messages that contain 771 it. 773 2.5. Associating Client and Server Messages 775 Messages between clients and servers are associated with one another 776 using the Client Identifier option and the xid field. For each 777 transaction initiated by a client, the client MUST generate an xid 778 value that is unique for that client identifier and likely to be 779 unique across all client identifiers. For instance, a client might 780 start with a random xid and increment from there. The client 781 identifier option and xid field MUST be included in each message sent 782 by the client or the server. 784 The client MUST check the client identifier option and xid field in 785 each incoming message to ensure that they match the client identifier 786 and xid for an outstanding transaction. If not, the message MUST be 787 discarded. The server MUST check the client identifier option and xid 788 field in each incoming message to establish the proper context for 789 the message. If the message is inappropriate for its context, it 790 SHOULD be discarded. 792 A transaction can be an attempt to allocate a multicast address 793 (consisting of DISCOVER, OFFER, REQUEST, ACK, and NAK messages), an 794 attempt to renew a lease (consisting of RENEW, ACK, and NAK 795 messages), an attempt to release a previously allocated multicast 796 address (consisting of RELEASE, ACK, and NAK messages), or an attempt 797 to acquire configuration parameters (consisting of INFORM and ACK 798 messages). 800 2.6. Multicast Scopes 802 RFC 2365 [3] provides for dividing the multicast address space into a 803 number of administratively scopes. Routers should be configured so 804 that each scope corresponds to a particular partition of the network 805 into disjoint regions. Messages sent to a multicast address that 806 falls within a certain administrative scope should only be delivered 807 to hosts that have joined that multicast group *and* fall within the 808 same region as the sender. For instance, packets sent to an address 809 in the organization-local scope should only be delivered to hosts 810 that have joined that group and fall within the same organization as 811 the sender. 813 Different sets of scopes may be in effect at different places in the 814 network and at different times. Before attempting to allocate an 815 address from an administrative scope (other than global or link- 816 level scope, which are always in effect), a MADCAP client SHOULD 817 determine that the scope is in effect at its location at this time. 818 Several techniques that a MADCAP client may use to determine the set 819 of administrative scopes in effect (the scope list) are: manual 820 configuration or configuration via MADCAP (using the Multicast Scope 821 List option). 823 If a MADCAP client is unable to determine its scope list using one of 824 these techniques, it MAY temporarily assume a scope list consisting 825 of a single scope. If it is using IPv4, it SHOULD use IPv4 Local 826 Scope (239.255.0.0/16), with a maximum TTL of 16. If it is using 827 IPv6, it SHOULD use SCOP 3, with a maximum TTL of 16. Using this 828 temporary scope list, it MAY attempt to contact a MADCAP server that 829 can provide a scope list for it. 831 When a MADCAP client requests an address with a DISCOVER or REQUEST 832 message, it MUST specify the administrative scope from which the 833 address should be allocated. This scope is indicated with the 834 Multicast Scope option. Likewise, the server MUST include the 835 Multicast Scope option in all OFFER messages and all ACK messages 836 sent in response to REQUEST messages. 838 2.7. Multicast TTL 840 Another way to limit propagation of multicast messages is by setting 841 the TTL field before sending them. This technique has several 842 disadvantages in comparison to administratively scoped multicast 843 addresses, but it is currently in widespread usage. 845 In an environment where administrative scoping is not in use and TTL 846 scoping is, a MADCAP server MAY return a scope list that includes 847 artificial scopes with TTLs less than 255. The MADCAP client MAY then 848 allocate addresses from these scopes, but MUST NOT set the TTL field 849 of any packet sent to such an address to a value greater than the 850 maximum TTL indicated in the scope list. In particular, it is 851 recommended that the MADCAP Server Multicast Addresses associated 852 with the IPv4 Local Scope (or SCOP 3 for IPv6) be blocked so that 853 packets sent to them with TTL of 16 are not sent outside an 854 appropriate boundary. This will allow MADCAP clients to use their 855 default behavior for finding MADCAP servers. 857 In an environment where administrative scoping is in use, the maximum 858 TTLs in the scope list SHOULD be 255. The admin scope zone boundary 859 routers will prevent leakage of MADCAP packets beyond appropriate 860 limits. 862 2.8. Locating MADCAP Servers 864 There are several ways for a MADCAP client to locate a MADCAP server. 866 For instance, the client may obtain a DNS name or IP address from 867 DHCP or manual configuration. 869 One particularly convenient technique (and the recommended one) is 870 for the client to send an INFORM message to a MADCAP Server Multicast 871 Address and wait for ACK responses. This technique is described in 872 more detail in the next section. 874 2.9. MADCAP Server Multicast Address 876 Each multicast scope has an associated MADCAP Server Multicast 877 Address. This address has been reserved by the IANA as the address 878 with a relative offset of -1 from the last address of a multicast 879 scope. 881 A MADCAP client looking for servers that can provide multicast 882 allocation services MAY send an INFORM message to a MADCAP Server 883 Multicast Address. Any MADCAP servers listening to this address 884 SHOULD respond with a unicast ACK message to the client if they wish 885 to offer a response. 887 The MADCAP Server Multicast Address used by a client MAY be 888 established by configuration (manually or via DHCP). If a client has 889 no such configuration, it SHOULD use the MADCAP Server Multicast 890 Address associated with IPv4 Local Scope (or SCOP 3 for IPv6) with 891 maximum TTL of 16, unless otherwise configured. 893 2.10. Going Beyond the Local Scope 895 If a client receives no response to a message sent to a MADCAP Server 896 Multicast Address (after retransmission), it MAY send the message to 897 a larger scope and repeat this process as necessary. However, the 898 client MUST NOT send a MADCAP message to the MADCAP Server Multicast 899 Address associated with the global scope. 901 This technique allows MADCAP servers to provide services for scopes 902 in which they do not reside. However, this is a dangerous and 903 complicated technique and is *not* recommended at this time. 904 Therefore, MADCAP clients SHOULD only send multicast messages to the 905 MADCAP Server Multicast Address corresponding to the IPv4 Local Scope 906 (or SCOP 3, if using IPv6), unless configured otherwise. 908 MADCAP servers that wish to provide services for scopes in which they 909 do not reside MUST make special efforts to ensure that their services 910 meet clients' needs for largely conflict-free allocation and accurate 911 scope list information. In particular, coordinating with other 912 servers that provide services for this scope may be difficult. Also, 913 establishing which scope the client is in may be difficult. If a 914 MADCAP server is not prepared to provide services for scopes in which 915 it does not reside, it SHOULD ignore REQUEST, RENEW, and RELEASE 916 messages whose scope does not match (or is enclosed by) the scope of 917 the MADCAP Server Multicast Address on which the request was 918 received. It SHOULD also ignore INFORM messages that are not received 919 on the MADCAP Server Multicast Address for IPv4 Local Scope. 921 2.11. Clock Skew 923 The Current Time option is used to detect and handle clock skew 924 between MADCAP clients and servers. This option MUST be included in 925 any MADCAP message that includes an absolute time (such as the Start 926 Time option). It MAY be included in any DISCOVER, OFFER, REQUEST, or 927 ACK message. 929 Clock skew is a situation where two systems have clocks that are not 930 synchronized. MADCAP servers SHOULD expect and tolerate a small 931 amount of clock skew with their clients by ensuring that multicast 932 addresses are allocated for an extra period of time 933 [CLOCK_SKEW_ALLOWANCE] on either side of the lease given to the 934 client. However, large amounts of clock skew require special 935 handling. The value of [CLOCK_SKEW_ALLOWANCE] is implementation 936 dependent. A reasonable value might be one hour. 938 The Current Time option contains the sender's opinion of the current 939 time in UTC at or about the time the message was assembled. Because 940 of delays in transmission and processing, this value will rarely 941 match the receiver's opinion of the current time at the time the 942 option is processed by the receiver. 944 If a MADCAP server detects clock skew greater than 945 [CLOCK_SKEW_ALLOWANCE], it SHOULD ignore the client. The server MAY 946 log a message. While it would be possible for the server to correct 947 for the clock skew, this would probably cause other problems, such as 948 the client advertising a session with an incorrect time. This is an 949 error condition and should be handled as such. 951 2.12. Optional Features 953 Each MADCAP client or server MAY implement one or more optional 954 features. Optional features of MADCAP are identified with a two 955 octet feature code. 957 A MADCAP client MAY request, require, or indicate support for an 958 optional feature by including a Feature List option in a message. A 959 MADCAP server MUST either provide all required features for this 960 message or ignore that message. For more information about optional 961 features, see the description of the Feature List option. 963 Table 4 lists the feature codes defined at this time and sections 964 2.12.1 and 2.12.2 describe how these features work. 966 New MADCAP feature codes may only be defined by IETF Consensus, as 967 described in [7]. Basically, this means that they are defined by RFCs 968 approved by the IESG. 970 Feature Code Feature Name 971 ------------ ------------ 972 0 Server Mobility 973 1 Retry After 975 Table 4: MADCAP message types 977 2.12.1. Server Mobility 979 The Server Mobility feature allows an address allocated on one MADCAP 980 server to be renewed or released on a different MADCAP server. This 981 requires communication and coordination among MADCAP servers. The 982 primary benefits are immunity to the failure of a single MADCAP 983 server and perhaps greater performance through load balancing. 985 In order to take advantage of the Server Mobility feature, a MADCAP 986 client must ensure that the feature is implemented by both the server 987 that is used for the original allocation and the server that is used 988 for the renewal or release. The best way to ensure this is to include 989 the Server Mobility feature in the required list of a Feature List 990 option in the REQUEST message used to allocate the address (and the 991 DISCOVER message, if one is used). When the time comes to renew or 992 release the address, the client may, of course, send a unicast RENEW 993 or RELEASE message to the server from which it allocated the address. 994 However, if this server is unavailable, the client may send the RENEW 995 or RELEASE message to any other server that includes the Server 996 Mobility feature in its list of supported features. The client may 997 find such a server by (for instance) sending an INFORM message with a 998 required Server Mobility feature. 1000 If the MADCAP client does not want to require this feature when 1001 allocating addresses, it may include the feature in the requested 1002 list of a Feature List option and see if the server includes the 1003 feature in the supported list of a Feature List option in the ACK 1004 message. 1006 Even if the Server Mobility feature is used, there is no guarantee 1007 that a server will be available to perform the renewal or release or 1008 that the renewal or release will succeed. Server connectivity may 1009 have failed, for instance. 1011 2.12.2. Retry After 1013 The Retry After feature allows a MADCAP server to ask the MADCAP 1014 client to retry its request later, as may be required when allocating 1015 large numbers of addresses or allocating addresses for a long period 1016 of time. 1018 If a MADCAP client includes the Retry After feature in the supported 1019 list of a Feature List option in a REQUEST message, a MADCAP server 1020 that also implements the Retry After feature MAY decide to perform a 1021 future allocation. In this case, the MADCAP server will include an 1022 empty List of Address Ranges option in its ACK message, a Feature 1023 List option that includes the Retry After feature in the supported 1024 list, and a Retry Time option with a time after which the client 1025 should retry the REQUEST. 1027 The client MUST NOT include the Retry After feature in the requested 1028 or required list of a Feature List option, since the decision about 1029 whether Retry After is desirable should be left to the MADCAP server. 1031 At some later time (preferably after the time indicated in the Retry 1032 Time option), the client MAY send a REQUEST message with all the same 1033 options as the original REQUEST message (especially the Client 1034 Identifier option), but with a new xid value. The server MAY return 1035 a normal ACK or NAK message at this point or it MAY continue the 1036 transaction to a later time by including an empty List of Address 1037 Ranges option in its ACK message, a Feature List option that includes 1038 the Retry After feature in the supported list, and a Retry Time 1039 option with a later time after which the client should retry the 1040 REQUEST. 1042 At any point after receiving the initial ACK message with the Retry 1043 Time option, the client MAY terminate the allocation process and any 1044 accompanying lease by sending to the server performing the allocation 1045 (or another server if the Server Mobility feature is also in effect) 1046 a RELEASE message with the Client Identifier included in the original 1047 REQUEST message. 1049 The Retry After feature may also be used when renewing a lease. In 1050 this case, the description above applies except that the client sends 1051 a RENEW message instead of a REQUEST message. 1053 If a client sends a RENEW message with a Client Identifier that 1054 matches a lease which is currently undergoing allocation with the 1055 Retry After feature in response to a REQUEST message, the server 1056 SHOULD ignore the RENEW message. Also, if a client sends a RENEW 1057 message with a Client Identifier that matches a lease which is 1058 currently undergoing allocation with the Retry After feature in 1059 response to a RENEW message, but the options supplied with the two 1060 RENEW messages do not match, the server SHOULD ignore the second 1061 RENEW message. 1063 3. MADCAP Options 1065 The following options are defined for use in MADCAP messages. The 1066 options are listed in numerical order. 1068 3.1. End 1070 The End option marks the end of valid information in the options 1071 field. This option MUST be included at the end of the options field 1072 in each MADCAP message. 1074 The code for this option is 0, and its length is 0. 1076 Code Len 1077 +-----+-----+-----+-----+ 1078 | 0 | 0 | 1079 +-----+-----+-----+-----+ 1081 3.2. Lease Time 1083 This option is used in a client request (DISCOVER, REQUEST, or RENEW) 1084 to allow the client to request a lease time for the multicast 1085 address. In a server reply (OFFER or ACK), a MADCAP server uses this 1086 option to specify the lease time it is willing to offer. 1088 The time is in units of seconds, and is specified as a 32-bit 1089 unsigned integer. 1091 The code for this option is 1, and its length is 4. 1093 Code Len Lease Time 1094 +-----+-----+-----+-----+-----+-----+-----+-----+ 1095 | 1 | 4 | t1 | t2 | t3 | t4 | 1096 +-----+-----+-----+-----+-----+-----+-----+-----+ 1098 3.3. Server Identifier 1100 This option contains the IP address of a MADCAP server. A two octet 1101 address family (as defined by IANA) is stored first, followed by the 1102 address. The address family for this address is not determined by 1103 the addrfamily field so that addresses from one family may be 1104 allocated while communicating with a server via addresses of another 1105 family. 1107 All messages sent by a MADCAP server MUST include a Server Identifier 1108 option with the IP address of the server sending the message. 1110 MADCAP clients MUST include a Server Identifier option in multicast 1111 REQUEST messages in order to indicate which OFFER message has been 1112 accepted. 1114 The code for this option is 2, and its minimum length is 3. 1116 Code Len Address Family Address 1117 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 1118 | 2 | n | family | a1 | ... | 1119 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 1121 3.4. Client Identifier 1123 This option is used by MADCAP clients to specify their unique 1124 identifier. For more information about this option and how it is 1125 used, see section 2.4. 1127 The code for this option is 3, and its minimum length is 1. 1129 Code Len Client Identifier 1130 +-----+-----+-----+-----+-----+-----+--- 1131 | 3 | n | i1 | i2 | ... 1132 +-----+-----+-----+-----+-----+-----+--- 1134 3.5. Multicast Scope 1136 The multicast scope option is used by the client to indicate the 1137 requested multicast scope in a DISCOVER or REQUEST message. It is 1138 also used by the MADCAP server to indicate the scope of an assigned 1139 address. 1141 The client may obtain the scope list through the Multicast Scope List 1142 option or using some other means. The scope id is the first multicast 1143 address in the scope. The address family of the Scope ID is 1144 determined by the addrfamily field. 1146 The code for this option is 4, and its minimum length is 1. 1148 Code Len Scope ID 1149 +-----+-----+-----+-----+-----+----- 1150 | 4 | n | i1 | ... 1151 +-----+-----+-----+-----+-----+----- 1153 3.6. Option Request List 1155 This option is used by a MADCAP client in an INFORM message to 1156 request that certain options be included in the server's ACK 1157 response. The server SHOULD try to include the specified options in 1158 its response, but is not required to do so. 1160 The format of this option is a list of option codes. 1162 The code for this option is 5 and the minimum length is 2. 1164 Code Len Requested Options 1165 +-----+-----+-----+-----+-----+-----+---... 1166 | 5 | n | Option1 | 1167 +-----+-----+-----+-----+-----+-----+---... 1169 3.7. Start Time 1171 The Start Time option specifies the starting time for a multicast 1172 address lease. 1174 A client may include this option in a DISCOVER, RENEW, or REQUEST 1175 message to request a multicast address for use at a future time. A 1176 server may include this option in an OFFER message or in an ACK in 1177 response to REQUEST or RENEW message to indicate that a lease has 1178 been granted which starts at a future time. 1180 If the Start Time option is present, the IP Address Lease Time option 1181 specifies the duration of the lease beginning at the Start Time 1182 option value. 1184 If the Start Time option is present, the Current Time option MUST 1185 also be present, as described in section 2.11. 1187 The time value is an unsigned 32 bit integer in network byte order 1188 giving the number of seconds since 00:00 UTC, 1st January 1970. This 1189 can be converted to an NTP timestamp by adding decimal 2208988800. 1190 This time format will not wrap until the year 2106. 1192 The code for this option is 6 and the length is 4. 1194 Code Len Time 1195 +-----+-----+-----+-----+-----+-----+-----+-----+ 1196 | 6 | 4 | t1 | t2 | t3 | t4 | 1197 +-----+-----+-----+-----+-----+-----+-----+-----+ 1199 3.8. Number of Addresses Requested 1201 This option specifies the minimum and desired number of addresses 1202 requested by the client. It is only used in DISCOVER and REQUEST 1203 messages and is only sent by the client. 1205 The minimum and desired number of addresses requested are unsigned 16 1206 bit integers in network byte order. The minimum MUST be less than or 1207 equal to the desired number. If a message is received where this is 1208 not the case, the message MUST be ignored. 1210 The client MAY obtain more than one address either by repeating the 1211 protocol for every address or by requesting several addresses at the 1212 same time via this option. When the client is requesting only one 1213 address, this option SHOULD not be included. A MADCAP server 1214 receiving a DISCOVER or REQUEST packet including this option MUST 1215 include between minimum and desired number of addresses in any OFFER 1216 or ACK response. 1218 The code for this option is 7 and the length is 4. 1220 Code Len Minimum Desired 1221 +-----+-----+-----+-----+-----+-----+-----+-----+ 1222 | 7 | 4 | min | desired | 1223 +-----+-----+-----+-----+-----+-----+-----+-----+ 1225 3.9. Requested Language 1227 This option specifies the language in which the MADCAP client would 1228 like strings such as zone names to be returned. It is only included 1229 in an INFORM message sent by the client. It is an RFC 1766 [6] 1230 language tag. The proper way to handle this tag with respect to zone 1231 names is discussed further in the definition of the Multicast Scope 1232 List option. 1234 The code for this option is 8 and the minimum length is 0. 1236 Code Len Language Tag 1237 +-----+-----+-----+-----+-----+-...-+-----+ 1238 | 8 | n | L1 | | Ln | 1239 +-----+-----+-----+-----+-----+-...-+-----+ 1241 3.10. Multicast Scope List 1243 This option is sent by the server in an ACK message in response to an 1244 INFORM message sent by the client. 1246 If the client did not include a Requested Language option in its 1247 INFORM message, the MADCAP server SHOULD return all zone names for 1248 each zone. If the client included a Requested Language option in its 1249 INFORM message, the MADCAP server MUST return no more than one zone 1250 name for each zone. For each zone, the MADCAP server SHOULD first 1251 look for a zone name that matches the requested language tag (using a 1252 case-insensitive ASCII comparison). If any names match, one of them 1253 should be returned. Otherwise, the MADCAP server SHOULD choose 1254 another zone name to return (if any are defined). It SHOULD give 1255 preference to zone names that are marked to be used if no name is 1256 available in a desired language. 1258 The code for this option is 9 and the minimum length is 0. 1260 The format of the multicast scope list option is: 1262 Code Len Count Scope List 1263 +-----+-----+-----+-----+-----+-----+-...-+-----+ 1264 | 9 | p | m | L1 | | Lm | 1265 +-----+-----+-----+-----+-----+-----+-...-+-----+ 1267 The scope list is a list of m tuples, where each tuple is of the 1268 form, 1270 Scope ID Last Address TTL Name Encoded Name List 1271 Count 1272 +---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+ 1273 | ... ID ... | ... Last ... | T | n | EN1 | | ENn | 1274 +---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+ 1276 where Scope ID is the first multicast address in the scope, Last 1277 Address is the last multicast address in the scope, TTL is the 1278 multicast TTL value for the multicast addresses of the scope, and 1279 Name Count is the number of encoded names for this zone (which may be 1280 zero). The address family of the Scope ID and Last Address is 1281 determined by the addrfamily field. Each encoded name is of the form 1283 Name Lang Language Tag Name Name 1284 Flags Length Length 1285 +-----+-----+-----+-...-+-----+-----+-----+-...-+-----+ 1286 | F | q | L1 | | Lq | r | N1 | | Nr | 1287 +-----+-----+-----+-...-+-----+-----+-----+-...-+-----+ 1289 where Name Flags is a flags field with flags defined below, Lang 1290 Length is the length of the Language Tag in octets (which MUST NOT be 1291 zero), Language Tag is a language tag indicating the language of the 1292 zone name (as described in [6]), Name Length is the length of the 1293 Name in octets (which MUST NOT be zero), and Name is a UTF-8 [5] 1294 string indicating the name given to the scope zone. 1296 The high bit of the Name Flags field is set if the following name 1297 should be used if no name is available in a desired language. 1298 Otherwise, this bit is cleared. All remaining bits in the octet 1299 SHOULD be set to zero and MUST be ignored. 1301 The scope IDs of entries in the list MUST be unique and the scopes 1302 SHOULD be listed from smallest (topologically speaking) to largest. 1304 Example: 1306 There are two scopes supported by the multicast address allocation 1307 server: Inside abcd.com with addresses 239.192.0.0-239.195.255.255, 1308 and world with addresses 224.0.1.0-238.255.255.255. Then this option 1309 will be given as: 1311 Code Len Count 1312 +-----+-----+-----+-----+-----+... 1313 | 9 | 51 | 2 | 1314 +-----+-----+-----+-----+-----+... 1316 Scope ID Last Address TTL Name Name Lang Language 1317 Count Flags Length Tag 1318 +---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+... 1319 |239|192| 0 | 0 |239|195|255|255|10 | 1 | 128 | 2 | en | 1320 +---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+... 1322 Name 1323 Length Name 1324 +------+--+--+-...-+--+--+... 1325 | 15 | Inside abcd.com | 1326 +------+--+--+-...-+--+--+... 1328 Scope ID Last Address TTL Name Name Lang Language 1329 Count Flags Length Tag 1330 +---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+... 1331 |224| 0 | 1 | 0 |238|255|255|255|16 | 1 | 128 | 2 | en | 1332 +---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+... 1334 Name 1335 Length Name 1336 +------+--...--+ 1337 | 5 | world | 1338 +------+--...--+ 1340 3.11. List of Address Ranges 1342 This option is used by the server to provide the list of all the 1343 address ranges allocated to the client. 1345 This option is also used by the client when requesting a lease for a 1346 specific set of addresses. 1348 The address family of the addresses is determined by the addrfamily 1349 field. 1351 The code for this option is 10 and the minimum length is 0. 1353 Code Len Address Range List 1354 +-----+-----+-----+-----+-----+-----+-...-+-----+ 1355 | 10 | n | L1 | L2 | | Ln | 1356 +-----+-----+-----+-----+-----+-----+-...-+-----+ 1358 where the Address Range List is of the following format. 1360 StartAddress1 BlockSize1 StartAddress2 BlockSize2 ... 1361 +---+---+---+---+---+---+---+---+---+---+---+---+--...--+ 1362 | ... S1 ... |B11|B12| ... S2 ... |B21|B22| | 1363 +---+---+---+---+---+---+---+---+---+---+---+---+--...--+ 1365 3.12. Current Time 1367 This option is used to express what the sender thinks the current 1368 time is. This is useful for detecting clock skew. This option MUST be 1369 included if the Start Time or Maximum Start Time options are used, as 1370 described in section 2.11. 1372 The time value is an unsigned 32 bit integer in network byte order 1373 giving the number of seconds since 00:00 UTC, 1st January 1970. This 1374 can be converted to an NTP [4] timestamp by adding decimal 1375 2208988800. This time format will not wrap until the year 2106. 1377 The code for this option is 11 and the length is 4. 1379 Code Len Time 1380 +-----+-----+-----+-----+-----+-----+-----+-----+ 1381 | 11 | 4 | t1 | t2 | t3 | t4 | 1382 +-----+-----+-----+-----+-----+-----+-----+-----+ 1384 3.13. Feature List 1386 This option lists optional MADCAP features supported, requested, or 1387 required by the sender. This option MAY be included in any message 1388 sent by a MADCAP server or client. 1390 Optional features of MADCAP are identified with a two octet feature 1391 code. New MADCAP feature codes may only be defined by IETF 1392 Consensus, as described in [7]. Basically, this means that they are 1393 defined by RFCs approved by the IESG. 1395 The Feature List option consists of three separate lists: supported 1396 features, requested features, and required features. Each list 1397 consists of an unordered list of feature codes. Features in the 1398 supported list are features that the sender supports. Features in the 1399 requested list are features that the sender would like the receiver 1400 to support and use. However, it is OK if the receiver does not 1401 support or use those features. Features in the required list are 1402 features that the sender requires. If the receiver does not support 1403 those features, it MUST ignore the message. 1405 If a MADCAP client includes the Feature List option in a message, it 1406 MAY include features in any of the lists: supported, requested, and 1407 required. A MADCAP server that receives a message containing the 1408 Feature List option from a client MUST ignore the entire message if 1409 it does not support all of the features in the required list. If it 1410 supports all of the features in the required list, it MUST implement 1411 them as appropriate for this message. It SHOULD try to implement the 1412 features in the requested list and it MAY implement any of the 1413 features in the supported list. If an optional feature (such as 1414 Retry After) is not included in any part of the Feature List option 1415 included in the client's message (or if the client does not include a 1416 Feature List option in its message), the server MUST NOT use that 1417 feature in its response. If the server does respond to a client's 1418 message that includes a Feature List option, it MUST include a 1419 Feature List option listing the features that it supports and with an 1420 empty requested and required features list. 1422 The code for this option is 12 and the minimum length is 6. 1424 Code Len Supported Requested Required 1425 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 1426 | 12 | n | FL1 | FL2 | FL3 | 1427 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 1429 where each of the Feature Lists is of the following format: 1431 Feature Feature Feature 1432 Count Code 1 Code m 1433 +-----+-----+-----+-----+-...-+-----+-----+ 1434 | m | FC1 | | FCm | 1435 +-----+-----+-----+-----+-...-+-----+-----+ 1437 3.14. Retry Time 1439 The Retry Time option specifies the time at which a client should 1440 retry a REQUEST or RENEW message when using the Retry After feature. 1442 This option should only be sent by a MADCAP server in an ACK when 1443 responding to a REQUEST or RENEW message that includes the Retry 1444 After feature in the supported, requested, or required list. For more 1445 discussion of Retry After, see section 2.12.2. 1447 If the Retry Time option is present, the Current Time option MUST 1448 also be present. 1450 The time value is an unsigned 32 bit integer in network byte order 1451 giving the number of seconds since 00:00 UTC, 1st January 1970. This 1452 can be converted to an NTP timestamp by adding decimal 2208988800. 1453 This time format will not wrap until the year 2106. 1455 The code for this option is 13 and the length is 4. 1457 Code Len Time 1458 +-----+-----+-----+-----+-----+-----+-----+-----+ 1459 | 13 | 4 | t1 | t2 | t3 | t4 | 1460 +-----+-----+-----+-----+-----+-----+-----+-----+ 1462 3.15. Minimum Lease Time 1464 This option is used in a client request (DISCOVER, REQUEST, or RENEW) 1465 to allow the client to specify a minimum lease time for the multicast 1466 address. If a server cannot meet this minimum lease time, it SHOULD 1467 ignore a DISCOVER or send a NAK in response to a RENEW or REQUEST 1468 (unless it's a multicast REQUEST with a Server Identifier that 1469 doesn't match the server's, which should be ignored altogether). 1471 The time is in units of seconds, and is specified as a 32-bit 1472 unsigned integer. 1474 The code for this option is 14, and its length is 4. 1476 Code Len Lease Time 1477 +-----+-----+-----+-----+-----+-----+-----+-----+ 1478 | 14 | 4 | t1 | t2 | t3 | t4 | 1479 +-----+-----+-----+-----+-----+-----+-----+-----+ 1481 3.16. Maximum Start Time 1483 The Maximum Start Time option specifies the latest starting time that 1484 the client is willing to accept for a multicast address lease. 1486 A client may include this option in a DISCOVER, RENEW, or REQUEST 1487 message to specify that it does not want to receive a lease with a 1488 starting time later than the specified value. If a server cannot meet 1489 this maximum start time, it SHOULD ignore a DISCOVER or send a NAK in 1490 response to a RENEW or REQUEST (unless it's a multicast REQUEST with 1491 a Server Identifier that doesn't match the server's, which should be 1492 ignored altogether). 1494 If the Maximum Start Time option is present, the Current Time option 1495 MUST also be present, as described in section 2.11. 1497 The time value is an unsigned 32 bit integer in network byte order 1498 giving the number of seconds since 00:00 UTC, 1st January 1970. This 1499 can be converted to an NTP timestamp by adding decimal 2208988800. 1500 This time format will not wrap until the year 2106. 1502 The code for this option is 15 and the length is 4. 1504 Code Len Time 1505 +-----+-----+-----+-----+-----+-----+-----+-----+ 1506 | 15 | 4 | t1 | t2 | t3 | t4 | 1507 +-----+-----+-----+-----+-----+-----+-----+-----+ 1509 4. Security Considerations 1511 MADCAP has relatively basic security requirements. At present there 1512 is no way of enforcing authorized use of multicast addresses in the 1513 multicast routing/management protocols. Therefore, it is not 1514 possible to identify unauthorized use of multicast address by an 1515 adversary. Moreover, a multicast address allocated to a user/system 1516 can be used by other systems without violating terms of the multicast 1517 address allocation. For example, a system may reserve an address to 1518 be used for a work group session where each and every member of the 1519 work group is allowed to transmit packets using the allocated group 1520 address. In other words, the multicast address allocation protocol 1521 does not dictate how the address should be used, it only dictates the 1522 time period for which it can be used and who gets to release it or 1523 renew it. When an address is allocated to a system/user, it basically 1524 means that no other user/system (most likely) will be allocated that 1525 address for the time period, without any restrictions on its use. 1527 To protect against rogue MADCAP servers (mis-configured servers and 1528 intentional), clients in certain situations would like to 1529 authenticate the server. Similarly, for auditing or book-keeping 1530 purposes, the server may want to authenticate clients. Moreover, in 1531 some cases, the server may have certain policies in place to restrict 1532 number of addresses that are allocated to a system or a user. This 1533 feature is of much value when a well behaved but naive user or client 1534 requests a large number of addresses, and therefore, inadvertently 1535 impacts other users or systems. Therefore, an administrator may want 1536 to exert a limited amount of control based on the client 1537 identification. The client identification could be based on the 1538 system or user identity. In most practical situations, system 1539 identification will suffice, however, particularly in case of 1540 multi-user systems, at times, user identification will play an 1541 important role. Therefore, authentication capabilities based on user 1542 identification may be desirable. As usual, data integrity is a strong 1543 requirement and if not protected, can lead to many problems including 1544 denial of service attacks. 1546 In the case of MADCAP, confidentiality is not a strong requirement. 1547 In most of the cases, at least when a multicast address is in use, an 1548 adversary will be able to determine information that was contained in 1549 the MADCAP messages. In some cases, the users/systems may want to 1550 protect information in the MADCAP messages so that an adversary is 1551 not able to determine relevant information in advance and thus, plan 1552 an attack in advance. For example, if an adversary knows in advance 1553 (based on MADCAP messages) that a particular user has requested large 1554 number of address for certain time period and scope, he may be able 1555 to guess the purpose behind such request and target an attack. If 1556 MADCAP servers are configured to allow renewal or release purely on 1557 the basis of knowledge of the Client Identifier option (without 1558 consideration of authentication), preserving the confidentiality of 1559 MADCAP messages becomes more important. Also, there may be features 1560 added to the protocol in future that may have stronger 1561 confidentiality requirements. 1563 The IPSEC protocol [8] meets client/server identification and 1564 integrity protection requirements stated above, requires no 1565 modification to the MADCAP protocol, and leverages extensive work in 1566 IETF and industry. Therefore, when security is a strong requirement, 1567 IPSEC SHOULD be used for protecting all the unicast messages of 1568 MADCAP protocol. When IPSEC based security is in use, all the 1569 multicast packets except INFORM MUST be dropped by the MADCAP server. 1570 The prevalent implementations of IPSEC support client identification 1571 in form of system identification and do not support user 1572 identification. However, when desired, IPSEC with appropriate API's 1573 may be required to support user identification. 1575 5. IANA Considerations 1577 This document defines several number spaces (MADCAP options, MADCAP 1578 message types, MADCAP client identifier types, and MADCAP features). 1579 For all of these number spaces, certain values are defined in this 1580 specification. New values may only be defined by IETF Consensus, as 1581 described in [7]. Basically, this means that they are defined by RFCs 1582 approved by the IESG. 1584 6. Acknowledgments 1586 The authors would like to thank Rajeev Byrisetty, Steve Deering, 1587 Peter Ford, Mark Handley, Van Jacobson, David Oran, Thomas Pfenning, 1588 Dave Thaler, Ramesh Vyaghrapuri and the participants of the IETF for 1589 their assistance with this protocol. 1591 Much of this document is based on [1] and [2]. The authors of this 1592 document would like to express their gratitude to the authors of 1593 these previous works. Any errors in this document are solely the 1594 fault of the authors of this document. 1596 7. References 1598 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 1599 March 1997. 1601 [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor 1602 Extensions", RFC 2132, March 1997. 1604 [3] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, 1605 July 1998. 1607 [4] Mills, D., "Network Time Protocol (Version 3) Specification, 1608 Implementation and Analysis", RFC 1305, March 1992. 1610 [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1611 2279, January 1998. 1613 [6] Alvestrand, H., "Tags for the Identification of Languages", RFC 1614 1766, March 1995. 1616 [7] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 1617 Considerations Section in RFCs", RFC 2434, October 1998. 1619 [8] R. Atkinson, S. Kent, "Security Architecture for the Internet 1620 Protocol", RFC 2401, November 1998. 1622 8. Authors' Addresses 1624 Baiju V. Patel 1625 Intel Corp. 1626 2111 NE 25th Ave. 1627 Hillsboro, OR 97124 1629 Phone: 503 264 2422 1630 EMail: baiju.v.patel@intel.com 1632 Munil Shah 1633 Microsoft Corporation 1634 One Microsoft Way 1635 Redmond, WA 98052 1637 Phone: 425 703 3924 1638 Email: munils@microsoft.com 1640 Stephen R. Hanna 1641 Sun Microsystems, Inc. 1642 One Network Drive 1643 Burlington, MA 01803 1645 Phone: +1.781.442.0166 1646 Email: steve.hanna@sun.com 1648 APPENDIX A: Examples 1650 This appendix includes several examples of typical MADCAP protocol 1651 exchanges. 1653 1. Multicast Scope List Discovery 1655 In this example, a MADCAP client wants to determine the scope list in 1656 effect. The client is using IPv4, so it starts with by multicasting 1657 an INFORM packet to the MADCAP Server Multicast Address corresponding 1658 to IPv4 Local Scope. This packet includes the Client Identifier 1659 option, an Option Request List including the Multicast Scope List 1660 option code, and a Requested Language option containing the string 1661 "en", since the client is configured to prefer the English language. 1663 Two MADCAP servers respond by sending ACK messages. These ACK 1664 messages include the Client Identifier option and xid supplied by the 1665 client, the server's Server Identifier, and the Multicast Scope List 1666 with one name per scope (the one that most closely matches the 1667 language tag "en"). 1669 The following figure illustrates this exchange. 1671 Server Client Server 1672 v v v 1673 | | | 1674 | | | 1675 | _____________/|\_____________ | 1676 |/ INFORM | INFORM \| 1677 | | | 1678 | | | 1679 |\ | ____________/| 1680 | \_________ | / ACK | 1681 | ACK \ |/ | 1682 | \ | | 1683 | | | 1684 v v v 1686 Figure 2: Timeline diagram of messages exchanged 1687 in Multicast Scope List Discovery example 1689 2. Multicast Discovery and Address Allocation 1691 In this example, the MADCAP client wants to allocate a multicast 1692 address from the global scope for use during the next two hours. 1694 The client begins by multicasting a DISCOVER packet to the MADCAP 1695 Server Multicast Address associated with IPv4 Local Scope. This 1696 packet includes the Lease Time, Client Identifier, and Multicast 1697 Scope options. 1699 Any servers that receive the DISCOVER packet and can satisfy this 1700 request temporarily reserve an address for the client and unicast an 1701 OFFER packet to the client. These packets contain the Lease Time, 1702 Server Identifier, Client Identifier, and Multicast Scope options. 1704 After a suitable delay, the client multicasts a REQUEST packet to the 1705 MADCAP Server Multicast Address. This packet contains all of the 1706 options included in the DISCOVER packet, but also includes the Server 1707 Identifier option, indicating which server it has selected for the 1708 request. 1710 The server whose Server Identifier matches the one specified by the 1711 client responds with an ACK packet containing the options included in 1712 the OFFER packet, as well as a List of Address Ranges option listing 1713 the address allocated. All the other servers that had sent OFFER 1714 packets stop reserving an address for the client and forget about the 1715 whole exchange. 1717 The client now has a two hour "lease" on the multicast address. 1719 If the client had not received an ACK from the server, it would have 1720 retransmitted its REQUEST packet for a while. If it still received no 1721 response, it would start over with a new DISCOVER message. 1723 The following figure illustrates this exchange. 1725 Server Client Server 1726 (not selected) (selected) 1727 v v v 1728 | | | 1729 |Begin multicast address request| 1730 | | | 1731 | _____________/|\_____________ | 1732 |/ DISCOVER | DISCOVER \| 1733 | | | 1734 Reserves | Reserves 1735 Address | Address 1736 | | | 1737 |\ | ____________/| 1738 | \_________ | / OFFER | 1739 | OFFER \ |/ | 1740 | \ | | 1741 | Collects replies | 1742 | \| | 1743 | Selects Server | 1744 | | | 1745 | _____________/|\_____________ | 1746 |/ REQUEST | REQUEST \| 1747 | | | 1748 | | Commits address 1749 | | | 1750 | | _____________/| 1751 | |/ ACK | 1752 | | | 1753 | assignment complete | 1754 | | | 1755 v v v 1757 Figure 3: Timeline diagram of messages exchanged 1758 in Multicast Address Allocation example 1760 3. Lease Extension 1762 This is a continuation of the previous example. The client has 1763 already allocated a multicast address from the global scope for use 1764 during the next two hours. Half way through this two hour period, it 1765 decides that it wants to extend its lease for another hour. 1767 The client unicasts a RENEW packet to the server from which it 1768 allocated the address. This packet includes the Lease Time and Client 1769 Identifier options. The Client Identifier matches the one used for 1770 the original allocation. The time included in the Lease Time is two 1771 hours, since the client wants the lease to expire two hours from the 1772 current time. 1774 The server responds with an ACK packet indicating that the lease 1775 extension has been granted. This packet includes the Lease Time, 1776 Server Identifier, Client Identifier, Multicast Scope, and List of 1777 Address Ranges options. 1779 If the server did not want to grant the requested lease extension, it 1780 would have responded with a NAK packet with the Client Identifier 1781 option. 1783 The following figure illustrates this exchange. 1785 Client Server 1786 v v 1787 | | 1788 |\_____________ | 1789 | RENEW \| 1790 | | 1791 | Extends lease 1792 | | 1793 | _____________/| 1794 |/ ACK | 1795 | | 1796 | | 1797 v v 1799 Figure 4: Timeline diagram of messages exchanged 1800 in Lease Extension example 1802 4. Address Release 1804 This is a continuation of the previous example. The client has 1805 already allocated a multicast address and extended its lease for 1806 another two hours. Half an hour later, the client finishes its use of 1807 the multicast address and wants to release it so it can be reused. 1809 The client unicasts a RELEASE packet to the server from which it 1810 allocated the address. This packet includes the Client Identifier 1811 option. The Client Identifier matches the one used for the original 1812 allocation. When the server receives this packet, it cancels the 1813 client's lease on the address and sends an ACK packet to the client 1814 indicating that the lease has been released. This packet includes the 1815 Server Identifier and Client Identifier options. 1817 The following figure illustrates this exchange. 1819 Client Server 1820 v v 1821 | | 1822 |\_____________ | 1823 | RELEASE \| 1824 | | 1825 | Cancels lease 1826 | | 1827 | _____________/| 1828 |/ ACK | 1829 | | 1830 v v 1832 Figure 5: Timeline diagram of messages exchanged 1833 in Address Release example 1835 5. Unicast Address Allocation 1837 This is a continuation of the previous example. At some later time, 1838 the client decides to allocate another multicast address. Since it 1839 has recently worked with a server, it decides to try sending a 1840 unicast REQUEST to that server. If this doesn't work, it can always 1841 try a multicast DISCOVER, as illustrated in example 2. 1843 The client unicasts a REQUEST packet to the server from which it 1844 wants to allocate the address. This packet includes the Lease Time, 1845 Client Identifier, and Multicast Scope options. 1847 The server responds with an ACK packet containing the Lease Time, 1848 Client Identifier, and Multicast Scope options from the REQUEST 1849 packet, as well as the Server Identifier option and a List of Address 1850 Ranges option listing the address allocated. 1852 The client now has a lease on the multicast address. 1854 If the client had not received an ACK from the server, it would have 1855 retransmitted its REQUEST packet for a while. If it still received no 1856 response, it would start over with a multicast DISCOVER message. 1858 The following figure illustrates this exchange. 1860 Client Server 1861 v v 1862 | | 1863 |\_____________ | 1864 | REQUEST \| 1865 | | 1866 | Allocates address 1867 | | 1868 | _____________/| 1869 |/ ACK | 1870 | | 1871 v v 1873 Figure 6: Timeline diagram of messages exchanged 1874 in Unicast Address Allocation example