idnits 2.17.1 draft-ietf-malloc-madcap-07.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: ---------------------------------------------------------------------------- ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 50 pages 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 are 5 instances of too long lines in the document, the longest one being 7 characters 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: ---------------------------------------------------------------------------- == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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: 'NAME-OF-CONSTANT' on line 51 -- Looks like a reference, but probably isn't: 'XID-REUSE-INTERVAL' on line 2350 -- Looks like a reference, but probably isn't: 'RESPONSE-CACHE-INTERVAL' on line 2349 -- Looks like a reference, but probably isn't: 'DISCOVER-DELAY' on line 2345 -- Looks like a reference, but probably isn't: 'OFFER-HOLD' on line 2348 -- Looks like a reference, but probably isn't: 'NO-RESPONSE-DELAY' on line 2347 -- Looks like a reference, but probably isn't: 'EXTRA-ALLOCATION-TIME' on line 2346 -- Looks like a reference, but probably isn't: 'CLOCK-SKEW-ALLOWANCE' on line 2344 ** 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) ** Obsolete normative reference: RFC 1700 (ref. '10') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2460 (ref. '12') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2373 (ref. '13') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 1889 (ref. '14') (Obsoleted by RFC 3550) Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MALLOC working group Stephen R. Hanna, Sun Microsystems, Inc. 2 Internet Draft Baiju V. Patel, Intel Corp. 3 September 1999 Munil Shah, Microsoft Corp. 4 Expires: March 2000 draft-ietf-malloc-madcap-07.txt 6 Multicast Address Dynamic Client Allocation Protocol (MADCAP) 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document defines a protocol, Multicast Address Dynamic Client 32 Allocation Protocol (MADCAP), that allows hosts to request multicast 33 addresses from multicast address allocation servers. 35 1. Introduction 37 Multicast Address Dynamic Client Allocation Protocol (MADCAP) is a 38 protocol that allows hosts to request multicast address allocation 39 services from multicast address allocation servers. This protocol is 40 part of the Multicast Address Allocation Architecture being defined 41 by the IETF Multicast Address Allocation Working Group. However, it 42 may be used separately from the rest of that architecture as 43 appropriate. 45 1.1. Terminology 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [9]. 51 Constants used by this protocol are shown as [NAME-OF-CONSTANT], and 52 summarized in Appendix B. 54 1.2. Definitions 56 This specification uses a number of terms that may not be familiar to 57 the reader. This section defines some of these and refers to other 58 documents for definitions of others. 60 MADCAP client or client 61 A host requesting multicast address allocation services via MADCAP. 63 MADCAP server or server 64 A host providing multicast address allocation services via MADCAP. 66 Multicast 67 IP Multicast, as defined in [11] and modified in [12]. 69 Multicast Address 70 An IP multicast address or group address, as defined in [11] and 71 [13]. An identifier for a group of nodes. 73 Multicast Scope 74 A range of multicast addresses configured so that traffic sent to 75 these addresses is limited to some subset of the internetwork. See 76 [3] and [13]. 78 Scope ID 79 The lowest numbered address in a multicast scope. This definition 80 applies only within this document. 82 Scope Zone 83 One multicast scope may have several instances, which are known as 84 Scope Zones or zones, for short. 86 For instance, an organization may have multiple sites. Each site 87 might have its own site-local Scope Zone, each of which would be an 88 instance of the site-local Scope. However, a given interface on a 89 given host would only ever be in at most one instance of a given 90 scope. Messages sent by a host in a site-local Scope Zones to an 91 address in the site-local Scope would be limited to the site-local 92 Scope Zone containing the host. 94 Zone Name 95 A human readable name for a Scope Zone. An ISO 10646 character 96 string with an RFC 1766 [6] language tag. One zone may have several 97 zone names, each in a different language. For instance, a zone for 98 use within IBM's locations in Switzerland might have the names "IBM 99 Suisse", "IBM Switzerland", "IBM Schweiz", and "IBM Svizzera" with 100 language tags "fr", "en", "de", and "it". 102 Multicast Scope List 103 A list of multicast scope zones. 105 Since it can be difficult to determine which multicast scope zones 106 are in effect, MADCAP clients can ask MADCAP servers to supply a 107 Multicast Scope List listing all of the zones available to the 108 client. For each scope zone, the list includes the range of 109 multicast addresses for this scope, a maximum TTL or hop count to 110 be used for this scope, and one or more zone names for this scope 111 zone. 113 This definition applies only within this document. 115 1.3. Motivation and Protocol Requirements 117 For multicast applications to be deployed everywhere, there is a need 118 to define a protocol that any host may use to allocate multicast 119 addresses. Here are the requirements for such a protocol. 121 Quick response: The host should be able to allocate a multicast 122 address and begin to use it promptly. 124 Low network load: Hosts that are not allocating or deallocating 125 multicast addresses at the present time should not need to send or 126 receive any network traffic. 128 Support for intermittently connected or power managed systems: Hosts 129 should be able to be disconnected from the network, powered off, or 130 otherwise inaccessible except during the brief period during which 131 they are allocating a multicast address. 133 Multicast address scopes: The protocol must be able to allocate both 134 the administratively scoped and globally scoped multicast addresses. 136 Efficient use of address space: The multicast address space is fairly 137 small. The protocol should make efficient use of this scarce 138 resource. 140 Authentication: Because multicast addresses are scarce, it is 141 important to protect against hoarding of these addresses. One way to 142 do this is by authenticating clients. This is also a key prerequisite 143 for establishing policies. 145 Policy neutral: Allocation policies (such as who can allocate 146 addresses) should not be dictated by the protocol. 148 Conferencing support: When allocating an address for use in a 149 conferencing environment, members of the conference should be able to 150 modify a multicast address lease used for the conference. 152 1.4. Relationship with DHCP 154 MADCAP was originally based on DHCP. There are still some 155 similarities and it may be possible to share some code between a DHCP 156 implementation and a MADCAP implementation. However, MADCAP is 157 completely separate from DHCP, with no dependencies between the two 158 and many significant differences. 160 1.5. Protocol Overview 162 MADCAP is built on a client-server model, where hosts request address 163 allocation services from address allocation servers. When a MADCAP 164 client wishes to request a service, it unicasts or multicasts a 165 message to one or more MADCAP servers, each of which optionally 166 responds with a message unicast to the client. 168 All messages are UDP datagrams. The UDP data contains a fixed length 169 header and a variable length options field. Options are encoded in a 170 type-length-value format with two octets type and value fields. The 171 fixed fields are version, msgtype (message type), addrfamily (address 172 family), and xid (transaction identifier). 174 Retransmission is handled by the client. If a client sends a message 175 and does not receive a response, it may retransmit its request a few 176 times using an exponential backoff. To avoid executing the same 177 client request twice when a retransmitted request is received, 178 servers cache responses for a short period of time and resend cached 179 responses upon receiving retransmitted requests. 181 Each request contains a msgtype, an xid, and a Lease Identifier 182 option. Clients must ensure that this triple is probably unique 183 across all MADCAP messages received by a MADCAP server over a period 184 of [XID-REUSE-INTERVAL] (10 minutes). This allows the MADCAP server 185 to use this triple as the key in its response cache. 187 Messages sent by servers include the xid included in the original 188 request so that clients can match up responses with requests. 190 The msgtype field is a single octet that defines the "type" of a 191 MADCAP message. Currently defined message types are listed in Table 192 2. They are: DISCOVER, OFFER, REQUEST, RENEW, ACK, NAK, RELEASE, and 193 GETINFO. DISCOVER, REQUEST, RENEW, RELEASE, and GETINFO messages are 194 only sent by a client. OFFER, ACK, and NAK messages are only sent by 195 a server. 197 The REQUEST, RENEW, and RELEASE messages are used to request, renew, 198 or release a lease on one or more multicast addresses. A client 199 unicasts one of these messages to a server and the server responds 200 with an ACK or a NAK. 202 The GETINFO message is used to request information, such as the 203 multicast scope list, or to find MADCAP servers. A client may unicast 204 an GETINFO message to a MADCAP server. However, it may not know the 205 IP address of any MADCAP server. In that case, it will multicast an 206 GETINFO message to a MADCAP Server Multicast Address and all servers 207 that wish to respond will send a unicast ACK or NAK back to the 208 client. 210 Each multicast scope has an associated MADCAP Server Multicast 211 Address. This address has been reserved by the IANA as the address 212 with a relative offset of -1 from the last address of a multicast 213 scope. MADCAP clients use this address to find MADCAP servers. 215 The DISCOVER message is a message used to discover MADCAP servers 216 that can probably satisfy a REQUEST. DISCOVER messages are always 217 multicast. Servers that can probably satisfy a REQUEST corresponding 218 to the parameters supplied in the DISCOVER message temporarily 219 reserve the addresses needed and send a unicast OFFER back to the 220 client. The client selects a server with which to continue and sends 221 a multicast REQUEST including the server's Server Identifier to the 222 same multicast address used for the DISCOVER. The chosen server 223 responds with an ACK or NAK and the other servers stop reserving the 224 addresses they were temporarily holding. 226 For detailed descriptions of typical protocol exchanges, consult 227 Appendix A. 229 MADCAP is a mechanism rather than a policy. MADCAP allows local 230 system administrators to exercise control over configuration 231 parameters where desired. For example, MADCAP servers may be 232 configured to limit the number of multicast addresses allocated to a 233 single client. Properly enforcing such a limit requires cryptographic 234 security, as described in the Security Consideration section. 236 MADCAP requests from a single host may be sent on behalf of different 237 applications with different needs and requirements. MADCAP servers 238 MUST NOT assume that because one request from a MADCAP client 239 supports a particular optional feature (like Retry After), future 240 requests from that client will also support that optional feature. 242 2. Protocol Description 244 The MADCAP protocol is a client-server protocol. In general, the 245 client unicasts or multicasts a message to one or more servers, which 246 optionally respond with messages unicast to the client. 248 A reserved port number dedicated for MADCAP is used on the server 249 (port number 2535, as assigned by IANA). Any port number may be used 250 on client machines. When a MADCAP server sends a message to a MADCAP 251 client, it MUST use a destination port number that matches the source 252 port number provided by the client in the message that caused the 253 server to send its message. 255 The next few sections describe the MADCAP message format and message 256 types. A full list of MADCAP options is provided in section 3. 258 2.1. Message Format 260 Figure 1 gives the format of a MADCAP message and Table 1 describes 261 each of the fields in the MADCAP message. The numbers in parentheses 262 indicate the size of each field in octets. The names for the fields 263 given in the figure will be used throughout this document to refer to 264 the fields in MADCAP messages. 266 All multi-octet quantities are in network byte-order. 268 Any message whose UDP data is too short to hold this format (at least 269 12 bytes) MUST be ignored. 271 +-+-+-+-+-+-+-+-+ 272 | version (1) | 273 +---------------+ 274 | msgtype (1) | 275 +---------------+ 276 | addrfamily | 277 | (2) | 278 +---------------+ 279 | | 280 | xid (4) | 281 | | 282 | | 283 +---------------+ 284 | | 285 | options | 286 | (variable) | 287 | ... | 288 +---------------+ 290 Figure 1: Format of a MADCAP message 292 FIELD OCTETS DESCRIPTION 293 ----- ------ ----------- 295 version 1 Protocol version number (zero for this specification) 296 msgtype 1 Message type (DISCOVER, GETINFO, etc.) 297 addrfamily 2 Address family (IPv4, IPv6, etc.) 298 xid 4 Transaction ID 299 options var Options field 301 Table 1: Description of fields in a MADCAP message 303 2.1.1. The version field 305 The version field must always be zero for this version of the 306 protocol. Any messages that include other values in this field MUST 307 be ignored. 309 2.1.2. The msgtype field 311 The msgtype field defines the "type" of the MADCAP message. 313 For more information about this field, see section 2.2. 315 2.1.3. The addrfamily field 317 The addrfamily field defines the default address family (such as IPv4 318 or IPv6) for this MADCAP message, using the address family numbers 319 defined in by the IANA (including those defined in [10]). Unless 320 otherwise specified, all addresses included in the message will be 321 from this family. 323 2.1.4. The xid field 325 The xid field is a transaction identifier. This number MUST be chosen 326 by the client so that the combination of xid, msgtype, and Lease 327 Identifier is unique across all MADCAP messages received by a MADCAP 328 server over a period of [XID-REUSE-INTERVAL] (10 minutes). 330 The xid field is used by the client and server to associate messages 331 and responses between a client and a server. Before a client sends a 332 message, it chooses a number to use as an xid. The technique used to 333 choose an xid is implementation-dependent, but whatever technique is 334 used MUST make it unlikely that the same combination of xid, msgtype, 335 and Lease Identifier will be used for two different messages within 336 [XID-REUSE-INTERVAL] (even across multiple clients which do not 337 communicate among themselves). This allows enough time for the 338 message to be dropped from all server response caches (as described 339 in the next few paragraphs) and for any network delays to be 340 accomodated. 342 The RECOMMENDED technique for choosing an xid is to choose a random 343 four octet number as the first xid in a session and increment this 344 value each time a new xid is needed. The random number chosen need 345 not be cryptographically random. The random number may be chosen via 346 any suitable technique, such as the one described in section A.6 of 347 RFC 1889 [14]. 349 When a server responds to a client message, it MUST use the same xid 350 value in the response that the client used in the request. This 351 allows the client to associate responses with the message that they 352 are responding to. 354 When retransmitting messages (as described in section 2.3), the 355 client MUST retransmit them without changing them, thereby using the 356 same xid and and Lease Identifier. 358 If a server receives a message with the same xid, msgtype, and Lease 359 Identifier as one received within [RESPONSE-CACHE-INTERVAL], it MUST 360 treat this message as a retransmission of the previously received one 361 and retransmit the response, if any. After [RESPONSE-CACHE-INTERVAL], 362 the server may forget about the previously received message and treat 363 any retransmissions of this message as if they were new messages. Of 364 course, a server need not cache a message if it ends up ignoring that 365 message. However, performance gains may be achieved by doing so. 367 This avoids retransmissions causing multiple allocations, since 368 requests are not idempotent. An appropriate value for [RESPONSE- 369 CACHE-INTERVAL] would be sixty seconds, but it may have any value 370 from zero seconds to 300 seconds (five minutes) and may be adjusted 371 dynamically according to resource constraints on the server. 372 However, using a value less than sixty seconds is NOT RECOMMENDED 373 because this is the normal client retransmission period. 375 2.1.5. The options field 377 The options field consists of a list of tagged parameters that are 378 called "options". All options consist of a two octet option code and 379 a two octet option length, followed by the number of octets specified 380 by the option length. In the case of some options, the length field 381 is a constant but must still be specified. 383 The option field MUST contain a sequence of options with the last one 384 being the End option (option code 0). Any message whose options field 385 does not conform to this syntax MUST be ignored. 387 Any MADCAP client or server sending a MADCAP message MAY include any 388 of the options listed in section 3, subject to the restrictions in 389 Table 5 and elsewhere in this document. They MAY also include other 390 MADCAP options that are defined in the future. A MADCAP client or 391 server MUST NOT include more than one option with the same option 392 type in one MADCAP message. 394 All MADCAP clients and servers MUST recognize all options listed in 395 this document and behave in accordance with this document when 396 receiving and processing any of these options. Any unrecognized 397 options MUST be ignored and the rest of the message processed as if 398 the unknown options were not present. If a MADCAP server receives a 399 message that does not conform to the requirements of this document 400 (for instance, not including all required options), an Invalid 401 Request error MUST be generated and processed in the manner described 402 in section 2.6. If a MADCAP client receives a message that does not 403 conform to the requirements of this document, it MUST ignore the 404 message. 406 The order of options within a message has no significance and any 407 order MUST be supported in an equivalent manner, with the exception 408 that the End option must occur once per message, as the last option 409 in the option field. 411 New MADCAP option codes may only be defined by IETF Consensus, as 412 described in section 5. 414 2.2. Message Types 416 The msgtype field defines the "type" of a MADCAP message. Legal 417 values for this field are: 419 Value Message Type 420 ----- ------------ 421 1 DISCOVER 422 2 OFFER 423 3 REQUEST 424 4 RENEW 425 5 ACK 426 6 NAK 427 7 RELEASE 428 8 GETINFO 430 Table 2: MADCAP message types 432 Throughout this document, MADCAP messages will be referred to by the 433 type of the message; e.g., a MADCAP message with a message type of 8 434 will be referred to as an GETINFO message. 436 Here are descriptions of the MADCAP message types. Table 5, which 437 appears at the beginning of section 3, summarizes which options are 438 allowed with each message type. 440 MADCAP clients and servers MUST handle all MADCAP message types 441 defined in this document in a manner consistent with this document. 443 If a MADCAP server receives a message whose message type it does not 444 recognize, an Invalid Request error MUST be generated and processed 445 in the manner described in section 2.6. If a MADCAP client receives a 446 message whose message type it does not recognize, it MUST ignore the 447 message. 449 Note, however, that under some circumstances this document requires 450 or suggests that clients or servers ignore messages with certain 451 message types even though they may be recognized. For instance, 452 clients that do not send DISCOVER messages SHOULD ignore OFFER 453 messages. Also, secure servers SHOULD ignore DISCOVER messages and 454 all servers SHOULD ignore DISCOVER messages that they cannot satisfy. 456 New MADCAP message types may only be defined by IETF Consensus, as 457 described in section 5. 459 2.2.1. GETINFO 461 The GETINFO message is used by a MADCAP client that wants to acquire 462 configuration parameters, especially a multicast scope list. This 463 message also allows a client to determine which servers are likely to 464 be able to handle future requests. 466 The MADCAP client sends out an GETINFO message. The message may be 467 unicast to a particular MADCAP server or multicast to a MADCAP Server 468 Multicast Address. For more details about the MADCAP Server Multicast 469 Address, see section 2.10. 471 If a server receives an GETINFO message and it can process the 472 request successfully, it MUST unicast an ACK message to the client. 473 All GETINFO messages MUST include an Option Request List option. The 474 server SHOULD try to include the specified options in its response, 475 but is not required to do so (especially if it does not recognize 476 them). 478 If a server receives an GETINFO message and it does not process the 479 request successfully, it MUST generate and process an error in the 480 manner described in section 2.6. 482 If a client sends an GETINFO message and does not receive any ACK 483 messages in response, it SHOULD resend its GETINFO message, as 484 described in section 2.3. 486 When a MADCAP client sends an GETINFO message, it MAY include the 487 Requested Language option, which specifies which language the client 488 would prefer for the zone names in the Multicast Scope List. The 489 proper way to handle this tag with respect to zone names is discussed 490 in the definition of the Multicast Scope List option. 492 2.2.2. DISCOVER 494 The DISCOVER message is a multicast message sent by a MADCAP client 495 that wants to discover MADCAP servers that can probably satisfy a 496 REQUEST. 498 MADCAP clients are not required to use the DISCOVER message. They 499 MAY employ other methods to find MADCAP servers, such as sending a 500 multicast GETINFO message, caching an IP address that worked in the 501 past or being configured with an IP address. Using the DISCOVER 502 message has the particular advantage that it allows clients to 503 receive responses from all servers that can satisfy the request. 505 The MADCAP client begins by sending a multicast DISCOVER message to a 506 MADCAP Server Multicast Address. Any servers that wish to assist the 507 client respond by sending a unicast OFFER message to the client. If a 508 server can only process the request with a shorter lease time or 509 later start time than the client requested, it SHOULD send an OFFER 510 message with the lease time or start time that it can offer. 511 However, it MUST NOT offer a lease time shorter than the minimum 512 lease time specified by the client or a start time later than the 513 maximum start time specified by the client. 515 For more details about the MADCAP Server Multicast Address, see 516 section 2.10. 518 If a client sends a DISCOVER message and does not receive any OFFER 519 messages in response, the client SHOULD retransmit its DISCOVER 520 message, as described in section 2.3. 522 If a client sends a DISCOVER message and receives one or more OFFER 523 messages in response, it SHOULD select the server it wants to use (if 524 any) and send a multicast REQUEST message identifying that server 525 within [DISCOVER-DELAY] after receiving the first OFFER message. See 526 section 2.2.4 for more information about the REQUEST message. 528 The mechanism used by the client in selecting the server it wants to 529 use is implementation dependent. The client MAY choose the first 530 acceptable response or it MAY wait some period of time (no more than 531 [DISCOVER-DELAY]) and choose the best response received in that 532 period of time (if the first response has a smaller lease time than 533 requested, for instance). 535 The value of [DISCOVER-DELAY] is also implementation dependent, but 536 the RECOMMENDED value is the current retransmit timer, as specified 537 in section 2.3. Waiting too long (approaching [OFFER-HOLD]) may cause 538 servers to drop the addresses they have reserved. 540 When a MADCAP client sends a DISCOVER message, it MAY include the 541 Lease Time, Minimum Lease Time, Start Time, Maximum Start Time, 542 Number of Addresses Requested, and List of Address Ranges options, 543 describing the addresses it wants to receive. However, it need not 544 include any of these options. If one of these options is not 545 included, the server will provide the appropriate default (maximum 546 available for Lease Time, no minimum for Minimum Lease Time, as soon 547 as possible for Start Time, no maximum for Maximum Start Time, one 548 for Number of Addresses Requested, and any addresses available for 549 List of Address Ranges). The Multicast Scope option MUST be included 550 in the DISCOVER message so that the server knows what scope should be 551 used. The Current Time option MUST be included if the Start Time or 552 Maximum Start Time options are included. The Lease Identifier option 553 MUST always be included. 555 2.2.3. OFFER 557 The OFFER message is a unicast message sent by a MADCAP server in 558 response to a DISCOVER message that it can probably satisfy. 560 A MADCAP server is never required to send an OFFER message in 561 response to a DISCOVER message. For instance, it may not be able to 562 satisfy the client's request or it may have been configured to 563 respond only to certain types of DISCOVER messages or not to respond 564 to DISCOVER messages at all. 566 If a MADCAP server decides to send an OFFER message, it MUST include 567 the Lease Time and Multicast Scope options, describing the addresses 568 it is willing to provide. However, it need not include the List of 569 Address Ranges option. If the List of Address Ranges Allocated option 570 is not included, it is assumed that the server is willing to provide 571 the number of addresses that the client requested. If the Start Time 572 option is not included, it is assumed that the server is willing to 573 provide the start time requested by the client (if any). The Current 574 Time option MUST be included if the Start Time option is included. 576 If a server can process the request with a shorter lease time or 577 later start time than the client requested, it SHOULD send an OFFER 578 message with the lease time or start time that it can offer. 579 However, it MUST NOT offer a lease time shorter than the minimum 580 lease time specified by the client or a start time later than the 581 maximum start time specified by the client. 583 If the server sends an OFFER message, it SHOULD attempt to hold 584 enough addresses to complete the transaction. If it receives a 585 multicast REQUEST message with the same Lease Identifier option as 586 the DISCOVER message for which it is holding these addresses and a 587 Server Identifier option that does not match its own, it SHOULD stop 588 holding the addresses. The server SHOULD also stop holding the 589 addresses after an appropriate delay [OFFER-HOLD] if the transaction 590 is not completed. The value of this delay is implementation-specific, 591 but a value of at least 60 seconds is RECOMMENDED. 593 As with all messages sent by the server, the xid field MUST match the 594 xid field included in the client request to which this message is 595 responding. The Lease Identifier option MUST be included, with the 596 value matching the one included in the client request. The Server 597 Identifier option MUST be included, with the value being the server's 598 IP address. And the packet MUST NOT be retransmitted. 600 2.2.4. REQUEST 602 The REQUEST message is used by a MADCAP client that wants to allocate 603 one or more multicast addresses. It is not used for renewing an 604 existing lease. The RENEW message is used for that. 606 If a REQUEST message is completing a transaction initiated by a 607 DISCOVER message, the following procedure MUST be followed so that 608 all MADCAP servers know which server was selected. The client MUST 609 multicast a REQUEST message to the same MADCAP Server Multicast 610 Address that the DISCOVER message was sent to. The same Lease 611 Identifier used in the DISCOVER message MUST be used in the REQUEST 612 message. Also, the Server Identifier option MUST be included, using 613 the Server Identifier of the server selected. 615 If a REQUEST message is not completing a transaction initiated by a 616 DISCOVER message, the REQUEST message MUST be unicast to the MADCAP 617 server that the client wants to use. In this case, the Server 618 Identifier option MAY be included, but need not be. 620 If the selected server can process the request successfully, it 621 SHOULD unicast an ACK message to the client. Otherwise, it SHOULD 622 generate and process an error in the manner described in section 2.6. 623 If a server can process the request with a shorter lease time or 624 later start time than the client requested, it SHOULD send an ACK 625 message with the lease time or start time that it can offer. However, 626 it MUST NOT offer a lease time shorter than the minimum lease time 627 specified by the client or a start time later than the maximum start 628 time specified by the client. 630 When a MADCAP client sends a REQUEST message, it MAY include the 631 Lease Time, Minimum Lease Time, Start Time, Maximum Start Time, 632 Number of Addresses Requested, and List of Address Ranges options, 633 describing the addresses it wants to receive. However, it need not 634 include any of these options. If one of these options is not 635 included, the server will provide the appropriate default (maximum 636 available for Lease Time, no minimum for Minimum Lease Time, as soon 637 as possible for Start Time, no maximum for Maximum Start Time, one 638 for Number of Addresses Requested, and any addresses available for 639 List of Address Ranges). The Multicast Scope option MUST be included 640 in the REQUEST message so that the server knows what scope should be 641 used. The Current Time option MUST be included if the Start Time or 642 Maximum Start Time options are included. 644 If a client sends a REQUEST message and does not receive any ACK or 645 NAK messages in response, the client SHOULD resend its REQUEST 646 message, as described in section 2.3. 648 If the server responds with a NAK or fails to respond within a 649 reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the 650 client MAY try to find another server by sending a DISCOVER message 651 with another xid or sending a REQUEST message with another xid to 652 another server. The RECOMMENDED value for [NO-RESPONSE-DELAY] is 60 653 seconds. 655 2.2.5. ACK 657 The ACK message is used by a MADCAP server to respond affirmatively 658 to an GETINFO, REQUEST, or RELEASE message. The server unicasts the 659 ACK message to the client from which it received the message to which 660 it is responding. 662 The set of options included with an ACK message differs, depending on 663 what sort of message it is responding to. 665 If the ACK message is responding to an GETINFO message, it SHOULD 666 include any options requested by the client using the Option Request 667 List option. 669 If the ACK message is responding to a REQUEST message, it MUST 670 include Lease Time, Multicast Scope, and List of Address Ranges 671 options. It MAY include a Start Time option. If a Start Time option 672 is included, a Current Time option MUST also be included. If no Start 673 Time option is included, the lease is assumed to start immediately. 675 If the ACK message is responding to a RENEW message, it MUST include 676 Lease Time, Multicast Scope, and List of Address Ranges options. It 677 MAY include a Start Time option. If a Start Time option is included, 678 a Current Time option MUST also be included. If no Start Time option 679 is included, the lease is assumed to start immediately. 681 If the ACK message is responding to a RELEASE message, it MUST only 682 include Server Identifier and Lease Identifier options. 684 As with all messages sent by the server, the xid field MUST match the 685 xid field included in the client request to which this message is 686 responding. The Lease Identifier option MUST be included, with the 687 value matching the one included in the client request. The Server 688 Identifier option MUST be included, with the value being the server's 689 IP address. And the packet MUST NOT be retransmitted. 691 2.2.6. NAK 693 The NAK message is used by a MADCAP server to respond negatively to a 694 message. The server unicasts the NAK message to the client from which 695 it received the message to which it is responding. 697 As with all messages sent by the server, the xid field MUST match the 698 xid field included in the client request to which this message is 699 responding. The Lease Identifier option MUST be included, with the 700 value matching the one included in the client request. The Server 701 Identifier option MUST be included, with the value being the server's 702 IP address. The Error option MUST be included with an error code 703 indicating what went wrong. And the packet MUST NOT be retransmitted. 705 2.2.7. RENEW 707 The RENEW message is used by a MADCAP client that wants to renew a 708 multicast address lease, changing the lease time or start time. 710 The client unicasts the RENEW message to a MADCAP server. If the 711 server can process the request successfully, it SHOULD unicast an ACK 712 message to the client. Otherwise, it MUST generate and process an 713 error in the manner described in section 2.6. 715 The lease to be renewed is whichever one was allocated with a Lease 716 Identifier option matching the one provided in the RENEW message. 718 When a MADCAP client sends a RENEW message, it MAY include the Lease 719 Time, Minimum Lease Time, Start Time, and Maximum Start Time options, 720 describing the new lease it wants to receive. However, it need not 721 include any of these options. If one of these options is not 722 included, the server will provide the appropriate default (maximum 723 available for Lease Time, no minimum for Minimum Lease Time, as soon 724 as possible for Start Time, and no maximum for Maximum Start Time). 725 The Current Time option MUST be included if the Start Time or Maximum 726 Start Time options are included. 728 If a client sends a RENEW message and does not receive any ACK or NAK 729 messages in response, the client SHOULD resend its RENEW message, as 730 described in section 2.3. 732 If the server responds with a NAK or fails to respond within a 733 reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the 734 client MAY send a RENEW message with another xid to another server, 735 provided that the Server Mobility feature was used in the original 736 REQUEST message and that this feature is required for the subsequent 737 RENEW message sent to another server. For more information about the 738 Server Mobility feature, see section 2.13.1. The RECOMMENDED value 739 for [NO-RESPONSE-DELAY] is 60 seconds. 741 2.2.8. RELEASE 743 The RELEASE message is used by a MADCAP client that wants to 744 deallocate one or more multicast addresses before their lease 745 expires. 747 The client unicasts the RELEASE message to the MADCAP server from 748 which it allocated the addresses. If the selected server can process 749 the request successfully, it MUST unicast an ACK message to the 750 client. Otherwise, it MUST generate and process an error in the 751 manner described in section 2.6. 753 The lease to be released is whichever one was allocated with a Lease 754 Identifier option matching the one provided in the RELEASE message. 755 It is not possible to release only part of the addresses in a single 756 lease. 758 If a client sends a RELEASE message and does not receive any ACK or 759 NAK messages in response, the client SHOULD resend its RELEASE 760 message, as described in section 2.3. 762 If the server responds with a NAK or fails to respond within a 763 reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the 764 client MAY send a RELEASE message with another xid to another server, 765 provided that the Server Mobility feature was used in the original 766 REQUEST message and that this feature is required for the subsequent 767 RELEASE message sent to another server. For more information about 768 the Server Mobility feature, see section 2.13.1. The RECOMMENDED 769 value for [NO-RESPONSE-DELAY] is 60 seconds. 771 2.3. Retransmission 773 MADCAP clients are responsible for all message retransmission. The 774 client MUST adopt a retransmission strategy that incorporates an 775 exponential backoff algorithm to determine the delay between 776 retransmissions. The delay between retransmissions SHOULD be chosen 777 to allow sufficient time for replies from the server to be delivered 778 based on the characteristics of the internetwork between the client 779 and the server. 781 The RECOMMENDED algorithm is to use a 4 second delay before the first 782 retransmission and to double this delay for each successive 783 retransmission, with a maximum delay of 16 seconds and a maximum of 784 three retransmissions. If an initial transmission was sent at time 785 (in seconds) t and no responses were received, subsequent 786 transmissions would be at t+4, t+12, and t+28. If no response has 787 been received by t+60, the client would stop retransmitting and take 788 another course of action (such as logging an error or sending a 789 message to another address. 791 The client MAY provide an indication of retransmission attempts to 792 the user as an indication of the progress of the process. The client 793 MAY halt retransmission at any point. 795 2.4. The Lease Identifier 797 The Lease Identifier option is included in each MADCAP message. Its 798 value is used to identify a lease and MUST be unique across all 799 leases requested by all clients in a multicast address allocation 800 domain. 802 The first octet of the Lease Identifier is the Lease Identifier type. 803 Table 3 lists the Lease Identifier types defined at this time and 804 sections 2.4.1 and 2.4.2 describe these Lease Identifier types. 806 New MADCAP Lease Identifier types may only be defined by IETF 807 Consensus, as described in section 5. 809 Lease Identifier Type Name 810 --------------------- ---- 811 0 Random Lease Identifier 812 1 Address-Specific Lease Identifier 814 Table 3: MADCAP Lease Identifier Types 816 The MADCAP server does not need to parse the Lease Identifier. It 817 SHOULD use the Lease Identifier only as an opaque identifier, which 818 must be unique for each lease. The purpose of defining different 819 Lease Identifier types is to allow MADCAP clients that already have a 820 globally unique address to avoid the possibility of Lease Identifier 821 collisions by using this address together with a client-specific 822 identifier. MADCAP clients that do not have a globally unique address 823 SHOULD use Lease Identifier type 0. 825 In addition to associating client and server messages (along with the 826 msgtype and xid fields, as described in the next section), the Lease 827 Identifier is used to determine which lease a RENEW or RELEASE 828 request refers to. MADCAP servers SHOULD match the Lease Identifier 829 included in a RENEW or RELEASE message with the Lease Identifier used 830 in an initial REQUEST message. If the Lease Identifier does not 831 match, a MADCAP server MUST generate and process a Lease Identifier 832 Not Recognized error in the manner described in section 2.6. 834 For conferencing applications, it may be desirable to allow 835 conference participants to modify a lease used for the conference. 836 The Shared Lease Identifier feature code is used to support this 837 requirement. If this feature code was requested by the client and 838 implemented by the server when the lease was allocated, the server 839 SHOULD disable any authentication requirements and allow any client 840 that knows the Lease Identifier to modify the lease. 842 As described in the Security Considerations section, MADCAP security 843 is not terribly useful without admission control in the multicast 844 routing infrastructure. However, if MADCAP security is desired when 845 using the Shared Lease Identifier feature, the confidentiality of the 846 Lease Identifier MUST be maintained by encrypting all messages that 847 contain it. A Lease Identifier that includes a long cryptographically 848 random number (at least eight octets in length) MUST be used in this 849 circumstance so that it is not easy to guess the Lease Identifier. 851 2.4.1. Random Lease Identifier 853 The first octet of a Random Lease Identifier is the Lease Identifier 854 type (0 to indicate Random Lease Identifier). After this come a 855 sequence of octets, which SHOULD represent a long random number (at 856 least 16 octets) from a decent random number generator. 858 A Random Lease Identifier does not include any indication of its 859 length. It is assumed that this may be determined by external means, 860 such as a length field preceding the Lease Identifier. 862 Lease ID 863 Type Random Number 864 +---------+-------------... 865 | 0 | 866 +---------+-------------... 868 2.4.2. Address-Specific Lease Identifier 870 The first octet of an Address-Specific Lease Identifier is the Lease 871 Identifier type (1 to indicate Address-Specific Lease Identifier). 872 After this comes a two octet IANA-defined address family number 873 (including those defined in [10]), an address from the specified 874 address family, and a client-specific identifier (such as a sequence 875 number or the current time). 877 An Address-Specific Lease Identifier does not include any indication 878 of its length. It is assumed that this may be determined by external 879 means, such as a length field preceding the Lease Identifier. 881 Lease ID Address Family Address Client-specific 882 Type Number Identifier 883 +---------+---------+---------+-----...-----+-----...-----+ 884 | 1 | addrfamily | address | cli-spec id | 885 +---------+---------+---------+-----...-----+-----...-----+ 887 2.5. Associating Client and Server Messages 889 Messages between clients and servers are associated with one another 890 using the Lease Identifier and the xid field. As described in section 891 2.1.4, the client MUST choose an xid so that it is unlikely that the 892 same combination of xid, msgtype, and Lease Identifier will be used 893 for two different messages within [XID-REUSE-INTERVAL] (even across 894 multiple clients which do not communicate among themselves). The 895 Lease Identifier option, msgtype, and xid field MUST be included in 896 each message sent by the client or the server. 898 The client MUST check the Lease Identifier option and xid field in 899 each incoming message to ensure that they match the Lease Identifier 900 and xid for an outstanding transaction. If not, the message MUST be 901 ignored. The server MUST check the Lease Identifier option and xid 902 field in each incoming message to establish the proper context for 903 the message. If a server cannot process a message because it is 904 invalid for its context, the server MUST generate and process an 905 Invalid Request error, as described in section 2.6. 907 A transaction can be an attempt to allocate a multicast address 908 (consisting of DISCOVER, OFFER, REQUEST, ACK, and NAK messages), an 909 attempt to renew a lease (consisting of RENEW, ACK, and NAK 910 messages), an attempt to release a previously allocated multicast 911 address (consisting of RELEASE, ACK, and NAK messages), or an attempt 912 to acquire configuration parameters (consisting of GETINFO, ACK, and 913 NAK messages). 915 2.6. Processing Errors 917 If a MADCAP server encounters an error while processing a message, 918 there are two different ways to process this error. If it is clear 919 that the message is not a NAK, the server SHOULD respond with a NAK 920 containing the appropriate Error option. However, the server MAY 921 decide to completely ignore chronic offenders. If the message is a 922 NAK or it is not clear whether the message is a NAK (for instance, 923 the message is garbled or has an incorrect version number), the 924 server SHOULD ignore the message. This avoids NAK loops. 926 If a MADCAP client encounters an error while processing a message, it 927 MUST ignore the message. 929 2.7. Multicast Scopes 931 RFC 2365 [3] provides for dividing the multicast address space into a 932 number of administrative scopes. Routers should be configured so that 933 each scope corresponds to a particular partition of the network into 934 disjoint regions. Messages sent to a multicast address that falls 935 within a certain administrative scope should only be delivered to 936 hosts that have joined that multicast group *and* fall within the 937 same region as the sender. For instance, packets sent to an address 938 in the organization-local scope should only be delivered to hosts 939 that have joined that group and fall within the same organization as 940 the sender. 942 Different sets of scopes may be in effect at different places in the 943 network and at different times. Before attempting to allocate an 944 address from an administrative scope (other than global or link- 945 level scope, which are always in effect), a MADCAP client SHOULD 946 determine that the scope is in effect at its location at this time. 947 Several techniques that a MADCAP client may use to determine the set 948 of administrative scopes in effect (the scope list) are: manual 949 configuration or configuration via MADCAP (using the Multicast Scope 950 List option). 952 If a MADCAP client is unable to determine its scope list using one of 953 these techniques, it MAY temporarily assume a scope list consisting 954 of a single scope. If it is using IPv4, it SHOULD use IPv4 Local 955 Scope (239.255.0.0/16), with a maximum TTL of 16. If it is using 956 IPv6, it SHOULD use SCOP 3, with a maximum hop count of 16. Using 957 this temporary scope list, it MAY attempt to contact a MADCAP server 958 that can provide a scope list for it. 960 When a MADCAP client requests an address with a DISCOVER or REQUEST 961 message, it MUST specify the administrative scope from which the 962 address should be allocated. This scope is indicated with the 963 Multicast Scope option. Likewise, the server MUST include the 964 Multicast Scope option in all OFFER messages and all ACK messages 965 sent in response to REQUEST messages. 967 2.8. Multicast TTL 969 Another way to limit propagation of multicast messages is by using 970 TTL scoping. This technique has several disadvantages in comparison 971 to administratively scoped multicast addresses (as described in [3]), 972 but it is currently in widespread usage. 974 With TTL scoping, areas of the network are designated as scopes. 975 Routers on the edges of these areas are configured with TTL 976 thresholds so that multicast packets are not forwarded unless their 977 remaining TTL exceeds this threshold. A packet which should be 978 restricted to a given TTL scope should have an initial TTL less than 979 that scope's TTL threshold. Similar techniques may be used with IPv6, 980 using the Hop Count field instead of the TTL field. 982 MADCAP may be used in an environment where administrative scoping is 983 not in use and TTL scoping is. Under these circumstances, a MADCAP 984 server MAY return a scope list that includes scopes with TTLs less 985 than 255. The MADCAP client MAY then allocate addresses from these 986 scopes, but MUST NOT set the TTL field of any packet sent to such an 987 address to a value greater than the maximum TTL indicated in the 988 scope list. In such an environment, it is recommended that the MADCAP 989 Server Multicast Addresses associated with the IPv4 Local Scope (or 990 SCOP 3 for IPv6) be configured using TTL thresholds so that packets 991 sent to these addresses with TTL of 16 are not sent outside an 992 appropriate boundary. This will allow MADCAP clients to use their 993 default behavior for finding MADCAP servers. 995 In an environment where administrative scoping is in use, the maximum 996 TTLs in the scope list SHOULD be 255. The admin scope zone boundary 997 routers will prevent leakage of MADCAP packets beyond appropriate 998 limits. 1000 2.9. Locating MADCAP Servers 1002 There are several ways for a MADCAP client to locate a MADCAP server. 1003 For instance, the client may be configured with an IP address. 1005 The RECOMMENDED technique is for the client to send an GETINFO 1006 message to a MADCAP Server Multicast Address and wait for ACK 1007 responses. This technique is described in more detail in the next 1008 section. 1010 2.10. MADCAP Server Multicast Address 1012 Each multicast scope has an associated MADCAP Server Multicast 1013 Address. This address has been reserved by the IANA as the address 1014 with a relative offset of -1 from the last address of a multicast 1015 scope. 1017 A MADCAP client looking for servers that can provide multicast 1018 allocation services MAY send an GETINFO message to a MADCAP Server 1019 Multicast Address. Any MADCAP servers listening to this address 1020 SHOULD respond with a unicast ACK message to the client if they wish 1021 to offer a response. 1023 The MADCAP Server Multicast Address used by a client MAY be 1024 established by configuration. If a client has no such configuration, 1025 it SHOULD use the MADCAP Server Multicast Address associated with 1026 IPv4 Local Scope (or SCOP 3 for IPv6) with maximum TTL of 16, unless 1027 otherwise configured. 1029 2.11. Going Beyond the Local Scope 1031 If a client receives no response to a message sent to a MADCAP Server 1032 Multicast Address (after retransmission), it MAY send the message to 1033 a larger scope and repeat this process as necessary. However, the 1034 client MUST NOT send a MADCAP message to the MADCAP Server Multicast 1035 Address associated with the global scope. 1037 This technique allows MADCAP servers to provide services for scopes 1038 in which they do not reside. However, this is a dangerous and 1039 complicated technique and is NOT RECOMMENDED at this time. 1040 Therefore, MADCAP clients SHOULD only send multicast messages to the 1041 MADCAP Server Multicast Address corresponding to the IPv4 Local Scope 1042 (or SCOP 3, if using IPv6), unless configured otherwise. 1044 MADCAP servers that wish to provide services for scopes in which they 1045 do not reside MUST make special efforts to ensure that their services 1046 meet clients' needs for largely conflict-free allocation and accurate 1047 scope list information. In particular, coordinating with other 1048 servers that provide services for this scope may be difficult. Also, 1049 establishing which scope the client is in may be difficult. If a 1050 MADCAP server is not prepared to provide services for scopes in which 1051 it does not reside, it SHOULD ignore DISCOVER and REQUEST messages 1052 whose scope does not match or enclose the scope of the MADCAP Server 1053 Multicast Address on which the request was received. It SHOULD also 1054 ignore GETINFO messages that are not received on the MADCAP Server 1055 Multicast Address for IPv4 Local Scope. 1057 2.12. Clock Skew 1059 The Current Time option is used to detect and handle clock skew 1060 between MADCAP clients and servers. This option MUST be included in 1061 any MADCAP message that includes an absolute time (such as the Start 1062 Time option). It MAY be included in any DISCOVER, OFFER, REQUEST, 1063 RENEW, or ACK message. 1065 Clock skew is a situation where two systems have clocks that are not 1066 synchronized. Many protocols (such as DHCP) ignore clock skew by 1067 using relative times. MADCAP could use a similar technique, but this 1068 leads to nasty situations due to the way multicast addresses are 1069 used. 1071 For example, assume that at 1 PM UTC a client whose clock is one hour 1072 fast requests a lease for one hour starting in one hour. If we were 1073 using relative times for MADCAP, the server, whose clock is set 1074 correctly, would reserve a multicast address for 2 to 3 PM UTC and 1075 grant the request. If the client was the only one using the lease, 1076 everything would be OK. The client would start using the lease in one 1077 hour and continue for one hour. This would coincide with the time the 1078 server had reserved (although the client would think it was 3 to 4 PM 1079 UTC). 1081 However, multicast addresses are usually used by several parties at 1082 once. The client would probably use SAP (or some other mechanism for 1083 conveying SDP) to advertise a session using the multicast address 1084 just leased. SDP uses absolute times, since it may be sent via email, 1085 web, or other store-and-forward mechanisms. So the client would 1086 advertise the session as running from 3 to 4 PM UTC. Any clients 1087 whose clocks are set correctly would use the address during this 1088 interval. Since the server only reserved the address from 2 to 3 PM 1089 UTC, this might cause the address to be used for multiple sessions 1090 simultaneously. 1092 MADCAP cannot solve all clock skew problems. That is the domain of 1093 NTP [4]. However, it does attempt to detect substantial clock skew 1094 between MADCAP clients and servers so that this clock skew does not 1095 cause massive collisions in multicast address usage later on. 1097 The Current Time option contains the sender's opinion of the current 1098 time in UTC at or about the time the message was assembled. Because 1099 of delays in transmission and processing, this value will rarely 1100 match the receiver's opinion of the current time at the time the 1101 option is processed by the receiver. However, difference greater than 1102 a minute or two probably indicate clock skew between the sender and 1103 the receiver. 1105 MADCAP servers SHOULD expect and tolerate a small amount of clock 1106 skew with their clients by ensuring that multicast addresses are 1107 allocated for an extra period of time [EXTRA-ALLOCATION-TIME] on 1108 either side of the lease given to the client. However, large amounts 1109 of clock skew require special handling. The value of [EXTRA- 1110 ALLOCATION-TIME] MUST be a configurable parameter, since local 1111 circumstances may vary. The RECOMMENDED default is one hour. 1113 However, large amounts of clock skew will cause problems later when 1114 sessions are advertised. If a MADCAP server detects clock skew 1115 greater than [CLOCK-SKEW-ALLOWANCE], it MUST generate and process an 1116 Excessive Clock Skew error, as described in section 2.6. The server 1117 MAY also log a message. The value of [CLOCK-SKEW-ALLOWANCE] MUST be a 1118 configurable parameter, since local circumstances may vary. The 1119 RECOMMENDED default is 30 minutes. 1121 2.13. Optional Features 1123 Each MADCAP client or server MAY implement one or more optional 1124 features. Optional features of MADCAP are identified with a two 1125 octet feature code. 1127 A MADCAP client MAY request, require, or indicate support for an 1128 optional feature by including a Feature List option in a message. For 1129 more information about optional features, see the description of the 1130 Feature List option. 1132 Table 4 lists the feature codes defined at this time and sections 1133 2.13.1 and 2.13.2 describe how these features work. 1135 New MADCAP feature codes may only be defined by IETF Consensus, as 1136 described in section 5. 1138 Feature Code Feature Name 1139 ------------ ------------ 1140 0 Server Mobility 1141 1 Retry After 1142 2 Shared Lease Identifier 1144 Table 4: MADCAP Feature Codes 1146 2.13.1. Server Mobility 1148 The Server Mobility feature allows an address allocated on one MADCAP 1149 server to be renewed or released on a different MADCAP server. This 1150 requires communication and coordination among MADCAP servers. The 1151 primary benefits are immunity to the failure of a single MADCAP 1152 server and perhaps greater performance through load balancing. 1154 In order to take advantage of the Server Mobility feature, a MADCAP 1155 client must ensure that the feature is implemented by both the server 1156 that is used for the original allocation and the server that is used 1157 for the renewal or release. The best way to ensure this is to include 1158 the Server Mobility feature in the required list of a Feature List 1159 option in the REQUEST message used to allocate the address (and the 1160 DISCOVER message, if one is used). When the time comes to renew or 1161 release the address, the client SHOULD send a unicast RENEW or 1162 RELEASE message to the server from which it allocated the address. 1163 However, if this server is unavailable, the client MAY send the RENEW 1164 or RELEASE message to any other server that includes the Server 1165 Mobility feature in its list of supported features. The client can 1166 find such a server by (for instance) sending an GETINFO message with 1167 an Option Request List option that includes the Feature List option 1168 code. 1170 If the MADCAP client does not want to require this feature when 1171 allocating addresses, it may include the feature in the requested 1172 list of a Feature List option and see if the server includes the 1173 feature in the required list of a Feature List option in the ACK 1174 message. 1176 Even if the Server Mobility feature is used, there is no guarantee 1177 that a server will be available to perform the renewal or release or 1178 that the renewal or release will succeed. Server connectivity may 1179 have failed, for instance. 1181 2.13.2. Retry After 1183 The Retry After feature allows a MADCAP server to ask the MADCAP 1184 client to retry its request later, as may be required when allocating 1185 large numbers of addresses or allocating addresses for a long period 1186 of time. 1188 For instance, if a MADCAP client requests 1000 addresses, 1189 administrative approval may be required or allocation of more 1190 addresses from another MASC domain may be necessary. This may take 1191 several hours or several days. If the MADCAP client and server both 1192 support the Retry After feature, the MADCAP server can send back an 1193 ACK message with a Retry Time option indicating when the addresses 1194 may be ready. The client can retry its request after the Retry Time 1195 to get the addresses. 1197 If a MADCAP client includes the Retry After feature in the supported 1198 list of a Feature List option in a REQUEST message, a MADCAP server 1199 that supports the Retry After feature MAY decide to begin a lengthy 1200 allocation process. In this case, the MADCAP server will include an 1201 empty List of Address Ranges option in its ACK message, a Feature 1202 List option that includes the Retry After feature in the required 1203 list, and a Retry Time option with a time after which the client 1204 should retry the REQUEST. 1206 The client MUST NOT include the Retry After feature in the requested 1207 or required list of a Feature List option, since the decision about 1208 whether Retry After is desirable should be left to the MADCAP server. 1210 At some later time (preferably after the time indicated in the Retry 1211 Time option), the client SHOULD send a REQUEST message with all the 1212 same options as the original REQUEST message (especially the Lease 1213 Identifier option), but with a new xid value. The server MAY return 1214 a normal ACK or NAK message at this point or it MAY continue the 1215 transaction to a later time by including an empty List of Address 1216 Ranges option in its ACK message, a Feature List option that includes 1217 the Retry After feature in the required list, and a Retry Time option 1218 with a later time after which the client should retry the REQUEST. 1220 At any point after receiving the initial ACK message with the Retry 1221 Time option, the client MAY terminate the allocation process and any 1222 accompanying lease by sending to the server performing the allocation 1223 (or another server if the Server Mobility feature is also in effect) 1224 a RELEASE message with the Lease Identifier included in the original 1225 REQUEST message. 1227 The Retry After feature may also be used when renewing a lease. In 1228 this case, the description above applies except that the client sends 1229 a RENEW message instead of a REQUEST message. 1231 If a client sends a RENEW message with a Lease Identifier that 1232 matches a lease which is currently undergoing allocation with the 1233 Retry After feature in response to a REQUEST message, the server MUST 1234 generate and process an Invalid Request error in the manner described 1235 in section 2.6. Also, if a client sends a RENEW message with a Lease 1236 Identifier that matches a lease which is currently undergoing 1237 allocation with the Retry After feature in response to a RENEW 1238 message, but the options supplied with the two RENEW messages do not 1239 match, the server MUST generate and process an Invalid Request error 1240 in the manner described in section 2.6. 1242 Note that the Retry After feature may complicate the application API. 1243 For this reason, a MADCAP client may request the Retry After feature 1244 for some messages and not for others. This should not cause problems 1245 for a robust MADCAP server. In general, servers should not expect 1246 consistent behavior from clients except as required by this 1247 specification. This also applies to clients' expectations. 1249 2.13.3. Shared Lease Identifier 1251 For conferencing applications, it may be desirable to allow 1252 conference participants to modify a lease used for the conference. 1253 The Shared Lease Identifier feature code is used to support this 1254 requirement. 1256 If this feature code was requested by the client and implemented by 1257 the server when the lease was allocated, the server SHOULD disable 1258 any authentication requirements pertaining to this lease, allowing 1259 any client that knows the Lease Identifier to modify the lease. 1261 A MADCAP client wishing to use the Shared Lease Identifier feature 1262 should include this feature in the requested or required lists of the 1263 Feature List option of a REQUEST message when first allocating the 1264 lease. If the feature was required, the server SHOULD try to 1265 implement it for this request and include the feature in the required 1266 list of the response. If the server can not implement the feature for 1267 this request, it MUST generate and process a Required Feature Not 1268 Supported error in the manner described in section 2.6. If the 1269 feature was requested, the server SHOULD try to implement the feature 1270 and include the feature in the required list of the response. 1271 However, if the server cannot implement the feature, it may simply 1272 skip it. 1274 Subsequent requests pertaining to a lease for which the Shared Lease 1275 Identifier feature was implemented at allocation time MAY include the 1276 Shared Lease Identifier feature in the requested or required lists of 1277 the Feature List option. In this case, the server SHOULD try to 1278 implement the feature by disabling any authentication requirements 1279 pertaining to this lease, allowing any client that knows the Lease 1280 Identifier to modify the lease, and including the feature in the 1281 required list of the response. If the server cannot implement the 1282 feature, it SHOULD skip it if the feature was requested. But if the 1283 feature was required and the server cannot implement it, the server 1284 MUST generate and process a Required Feature Not Supported error in 1285 the manner described in section 2.6. 1287 3. MADCAP Options 1289 As described earlier, each MADCAP message includes an options field 1290 consisting of a list of tagged parameters that are called "options". 1291 All options consist of a two octet option code and a two octet option 1292 length, followed by the number of octets specified by the option 1293 length. 1295 This section defines a set of option codes for use in MADCAP 1296 messages. New options may be defined using the process defined in 1297 section 5. The options are listed in numerical order. 1299 Table 5 summarizes which options are allowed with each message type. 1301 Option GETINFO ACK (in response to GETINFO) 1302 ------ ------ --------------------------- 1303 Lease Time MUST NOT MUST NOT 1304 Server Identifier MUST NOT MUST 1305 Lease Identifier MUST MUST 1306 Multicast Scope MUST NOT MUST NOT 1307 Option Request List MUST MUST NOT 1308 Start Time MUST NOT MUST NOT 1309 Number of Addresses 1310 Requested MUST NOT MUST NOT 1311 Requested Language MAY MUST NOT 1312 Multicast Scope List MUST NOT MAY 1313 List of Address Ranges MUST NOT MUST NOT 1314 Current Time MUST NOT MAY 1315 Feature List MAY MAY 1316 Retry Time MUST NOT MUST NOT 1317 Minimum Lease Time MUST NOT MUST NOT 1318 Maximum Start Time MUST NOT MUST NOT 1319 Error MUST NOT MUST NOT 1321 Option DISCOVER OFFER 1322 ------ -------- ----- 1323 Lease Time MAY MUST 1324 Server Identifier MUST NOT MUST 1325 Lease Identifier MUST MUST 1326 Multicast Scope MUST MUST 1327 Option Request List MUST NOT MUST NOT 1328 Start Time MAY MAY 1329 Number of Addresses 1330 Requested MAY MUST NOT 1331 Requested Language MUST NOT MUST NOT 1332 Multicast Scope List MUST NOT MUST NOT 1333 List of Address Ranges MAY MAY 1334 Current Time MAY MAY 1335 Feature List MAY MAY 1336 Retry Time MUST NOT MUST NOT 1337 Minimum Lease Time MAY MUST NOT 1338 Maximum Start Time MAY MUST NOT 1339 Error MUST NOT MUST NOT 1341 Option REQUEST ACK (in response to REQUEST) 1342 ------ ------- ---------------------------- 1343 Lease Time MAY MUST 1344 Server Identifier MUST (if MUST 1345 multicast) 1346 Lease Identifier MUST MUST 1347 Multicast Scope MUST MUST 1348 Option Request List MUST NOT MUST NOT 1349 Start Time MAY MAY 1350 Number of Addresses 1351 Requested MAY MUST NOT 1352 Requested Language MUST NOT MUST NOT 1353 Multicast Scope List MUST NOT MUST NOT 1354 List of Address Ranges MAY MUST 1355 Current Time MAY MAY 1356 Feature List MAY MAY 1357 Retry Time MUST NOT MAY 1358 Minimum Lease Time MAY MUST NOT 1359 Maximum Start Time MAY MUST NOT 1360 Error MUST NOT MUST NOT 1362 Option RENEW ACK (in response to RENEW) 1363 ------ ----- -------------------------- 1364 Lease Time MAY MUST 1365 Server Identifier MUST NOT MUST 1366 Lease Identifier MUST MUST 1367 Multicast Scope MUST NOT MUST 1368 Option Request List MUST NOT MUST NOT 1369 Start Time MAY MAY 1370 Number of Addresses 1371 Requested MUST NOT MUST NOT 1372 Requested Language MUST NOT MUST NOT 1373 Multicast Scope List MUST NOT MUST NOT 1374 List of Address Ranges MUST NOT MUST 1375 Current Time MAY MAY 1376 Feature List MAY MAY 1377 Retry Time MUST NOT MAY 1378 Minimum Lease Time MAY MUST NOT 1379 Maximum Start Time MAY MUST NOT 1380 Error MUST NOT MUST NOT 1382 Option RELEASE ACK (in response to RELEASE) 1383 ------ ------- ---------------------------- 1384 Lease Time MUST NOT MUST NOT 1385 Server Identifier MUST NOT MUST 1386 Lease Identifier MUST MUST 1387 Multicast Scope MUST NOT MUST NOT 1388 Option Request List MUST NOT MUST NOT 1389 Start Time MUST NOT MUST NOT 1390 Number of Addresses 1391 Requested MUST NOT MUST NOT 1392 Requested Language MUST NOT MUST NOT 1393 Multicast Scope List MUST NOT MUST NOT 1394 List of Address Ranges MUST NOT MUST NOT 1395 Current Time MUST NOT MUST NOT 1396 Feature List MAY MAY 1397 Retry Time MUST NOT MUST NOT 1398 Minimum Lease Time MUST NOT MUST NOT 1399 Maximum Start Time MUST NOT MUST NOT 1400 Error MUST NOT MUST NOT 1402 Option NAK 1403 ------ --- 1404 Lease Time MUST NOT 1405 Server Identifier MUST 1406 Lease Identifier MUST 1407 Multicast Scope MUST NOT 1408 Option Request List MUST NOT 1409 Start Time MUST NOT 1410 Number of Addresses 1411 Requested MUST NOT 1412 Requested Language MUST NOT 1413 Multicast Scope List MUST NOT 1414 List of Address Ranges MUST NOT 1415 Current Time MUST NOT 1416 Feature List MAY 1417 Retry Time MUST NOT 1418 Minimum Lease Time MUST NOT 1419 Maximum Start Time MUST NOT 1420 Error MUST 1422 Table 5: Options allowed in MADCAP messages 1424 3.1. End 1426 The End option marks the end of valid information in the options 1427 field. This option MUST be included at the end of the options field 1428 in each MADCAP message. 1430 The code for this option is 0, and its length is 0. 1432 Code Len 1433 +-----+-----+-----+-----+ 1434 | 0 | 0 | 1435 +-----+-----+-----+-----+ 1437 3.2. Lease Time 1439 This option is used in a client request (DISCOVER, REQUEST, or RENEW) 1440 to allow the client to request a lease time for the multicast 1441 address. In a server reply (OFFER or ACK), a MADCAP server uses this 1442 option to specify the lease time it is willing to offer. 1444 The time is in units of seconds, and is specified as a 32-bit 1445 unsigned integer. 1447 The code for this option is 1, and its length is 4. 1449 Code Len Lease Time 1450 +-----+-----+-----+-----+-----+-----+-----+-----+ 1451 | 1 | 4 | t1 | t2 | t3 | t4 | 1452 +-----+-----+-----+-----+-----+-----+-----+-----+ 1454 3.3. Server Identifier 1456 This option contains the IP address of a MADCAP server. A two octet 1457 address family number (as defined by IANA, including those defined in 1458 [10]) is stored first, followed by the address. The address family 1459 for this address is not determined by the addrfamily field in the 1460 fixed header so that addresses from one family may be allocated while 1461 communicating with a server via addresses of another family. 1463 All messages sent by a MADCAP server MUST include a Server Identifier 1464 option with the IP address of the server sending the message. 1466 MADCAP clients MUST include a Server Identifier option in multicast 1467 REQUEST messages in order to indicate which OFFER message has been 1468 accepted. 1470 The code for this option is 2, and its minimum length is 3. 1472 Code Len Address Family Address 1473 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 1474 | 2 | n | family | a1 | ... | 1475 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 1477 3.4. Lease Identifier 1479 This option is used by MADCAP clients to specify a unique lease 1480 identifier. For more information about this option and how it is 1481 used, see section 2.4. 1483 The code for this option is 3, and its minimum length is 1. 1485 Code Len Lease Identifier 1486 +-----+-----+-----+-----+-----+-----+--- 1487 | 3 | n | i1 | i2 | ... 1488 +-----+-----+-----+-----+-----+-----+--- 1490 3.5. Multicast Scope 1492 The multicast scope option is used by the client to indicate the 1493 requested multicast scope in a DISCOVER or REQUEST message. It is 1494 also used by the MADCAP server to indicate the scope of an assigned 1495 address. 1497 The client may obtain the scope list through the Multicast Scope List 1498 option or using some other means. The Scope ID is the first multicast 1499 address in the scope. The address family of the Scope ID is 1500 determined by the addrfamily field in the fixed header. 1502 The code for this option is 4, and its minimum length is 1. 1504 Code Len Scope ID 1505 +-----+-----+-----+-----+-----+----- 1506 | 4 | n | i1 | ... 1507 +-----+-----+-----+-----+-----+----- 1509 3.6. Option Request List 1511 This option is used by a MADCAP client in an GETINFO message to 1512 request that certain options be included in the server's ACK 1513 response. The server SHOULD try to include the specified options in 1514 its response, but is not required to do so. 1516 The format of this option is a list of option codes. 1518 The code for this option is 5 and the minimum length is 2. 1520 Code Len Requested Options 1521 +-----+-----+-----+-----+-----+-----+---... 1522 | 5 | n | Option1 | 1523 +-----+-----+-----+-----+-----+-----+---... 1525 3.7. Start Time 1527 The Start Time option specifies the starting time for a multicast 1528 address lease. 1530 A client may include this option in a DISCOVER, RENEW, or REQUEST 1531 message to request a multicast address for use at a future time. A 1532 server may include this option in an OFFER message or in an ACK in 1533 response to REQUEST or RENEW message to indicate that a lease has 1534 been granted which starts at a future time. 1536 If the Start Time option is present, the IP Address Lease Time option 1537 specifies the duration of the lease beginning at the Start Time 1538 option value. 1540 If the Start Time option is present, the Current Time option MUST 1541 also be present, as described in section 2.12. 1543 The time value is an unsigned 32 bit integer in network byte order 1544 giving the number of seconds since 00:00 UTC, 1st January 1970. This 1545 can be converted to an NTP timestamp by adding decimal 2208988800. 1546 This time format will not wrap until the year 2106. 1548 The code for this option is 6 and the length is 4. 1550 Code Len Time 1551 +-----+-----+-----+-----+-----+-----+-----+-----+ 1552 | 6 | 4 | t1 | t2 | t3 | t4 | 1553 +-----+-----+-----+-----+-----+-----+-----+-----+ 1555 3.8. Number of Addresses Requested 1557 This option specifies the minimum and desired number of addresses 1558 requested by the client. It is only used in DISCOVER and REQUEST 1559 messages and is only sent by the client. 1561 The minimum and desired number of addresses requested are unsigned 16 1562 bit integers in network byte order. The minimum MUST be less than or 1563 equal to the desired number. If a message is received where this is 1564 not the case, the MADCAP server MUST generate and process an Invalid 1565 Request error in the manner described in section 2.6. 1567 The client MAY obtain more than one address either by repeating the 1568 protocol for every address or by requesting several addresses at the 1569 same time via this option. When the client is requesting only one 1570 address, this option SHOULD NOT be included. A MADCAP server 1571 receiving a DISCOVER or REQUEST packet including this option MUST 1572 include between the minimum and desired number of addresses in any 1573 OFFER or ACK response. 1575 The code for this option is 7 and the length is 4. 1577 Code Len Minimum Desired 1578 +-----+-----+-----+-----+-----+-----+-----+-----+ 1579 | 7 | 4 | min | desired | 1580 +-----+-----+-----+-----+-----+-----+-----+-----+ 1582 3.9. Requested Language 1584 This option specifies the language in which the MADCAP client would 1585 like strings such as zone names to be returned. It is only included 1586 in an GETINFO message sent by the client. It is an RFC 1766 [6] 1587 language tag. The proper way to handle this tag with respect to zone 1588 names is discussed further in the definition of the Multicast Scope 1589 List option. 1591 The code for this option is 8 and the minimum length is 0. 1593 Code Len Language Tag 1594 +-----+-----+-----+-----+-----+-...-+-----+ 1595 | 8 | n | L1 | | Ln | 1596 +-----+-----+-----+-----+-----+-...-+-----+ 1598 3.10. Multicast Scope List 1600 This option is sent by the server in an ACK message in response to an 1601 GETINFO message sent by the client. 1603 If the client did not include a Requested Language option in its 1604 GETINFO message, the MADCAP server SHOULD return all zone names for 1605 each zone. If the client included a Requested Language option in its 1606 GETINFO message, the MADCAP server MUST return no more than one zone 1607 name for each zone. For each zone, the MADCAP server SHOULD first 1608 look for a zone name that matches the requested language tag (using a 1609 case-insensitive ASCII comparison). If any names match, one of them 1610 should be returned. Otherwise, the MADCAP server SHOULD choose 1611 another zone name to return (if any are defined). It SHOULD give 1612 preference to zone names that are marked to be used if no name is 1613 available in a desired language. 1615 The code for this option is 9 and the minimum length is 0. 1617 The format of the multicast scope list option is: 1619 Code Len Count Scope List 1620 +-----+-----+-----+-----+-----+-----+-...-+-----+ 1621 | 9 | p | m | L1 | | Lm | 1622 +-----+-----+-----+-----+-----+-----+-...-+-----+ 1624 The scope list is a list of m tuples, where each tuple is of the 1625 form: 1627 Scope ID Last Address TTL Name Encoded Name List 1628 Count 1629 +---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+ 1630 | ... ID ... | ... Last ... | T | n | EN1 | | ENn | 1631 +---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+ 1633 where Scope ID is the first multicast address in the scope, Last 1634 Address is the last multicast address in the scope, TTL is the 1635 multicast TTL value for the multicast addresses of the scope, and 1636 Name Count is the number of encoded names for this zone (which may be 1637 zero). The address family of the Scope ID and Last Address is 1638 determined by the addrfamily field in the fixed header. Note that a 1639 particular MADCAP server may be allocating addresses out of some 1640 subset of the scope. For instance, the addresses in the scope may be 1641 divided among several servers in some way. 1643 Each encoded name is of the form 1645 Name Lang Language Tag Name Name 1646 Flags Length Length 1647 +-----+-----+-----+-...-+-----+-----+-----+-...-+-----+ 1648 | F | q | L1 | | Lq | r | N1 | | Nr | 1649 +-----+-----+-----+-...-+-----+-----+-----+-...-+-----+ 1651 where Name Flags is a flags field with flags defined below, Lang 1652 Length is the length of the Language Tag in octets (which MUST NOT be 1653 zero), Language Tag is a language tag indicating the language of the 1654 zone name (as described in [6]), Name Length is the length of the 1655 Name in octets (which MUST NOT be zero), and Name is a UTF-8 [5] 1656 string indicating the name given to the scope zone. 1658 The high bit of the Name Flags field is set if the following name 1659 should be used if no name is available in a desired language. 1660 Otherwise, this bit is cleared. All remaining bits in the octet 1661 SHOULD be set to zero and MUST be ignored. 1663 The Scope IDs of entries in the list MUST be unique and the scopes 1664 SHOULD be listed from smallest (topologically speaking) to largest. 1665 This makes it easier to display a consistent user interface, with 1666 scopes usually keeping the same order. However, scopes may not be 1667 strictly nested. In this circumstance, there is no strict ordering 1668 from smallest to largest and the server must use another technique 1669 for ordering the scope list. 1671 Example: 1673 There are two scopes supported by the multicast address allocation 1674 server: Inside abcd.com with addresses 239.192.0.0-239.195.255.255, 1675 and world with addresses 224.0.1.0-238.255.255.255. Then this option 1676 will be given as: 1678 Code Len Count 1679 +-----+-----+-----+-----+-----+... 1680 | 9 | 51 | 2 | 1681 +-----+-----+-----+-----+-----+... 1683 Scope ID Last Address TTL Name Name Lang Language 1684 Count Flags Length Tag 1685 +---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+... 1686 |239|192| 0 | 0 |239|195|255|255|10 | 1 | 128 | 2 | en | 1687 +---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+... 1689 Name 1690 Length Name 1691 +------+--+--+-...-+--+--+... 1692 | 15 | Inside abcd.com | 1693 +------+--+--+-...-+--+--+... 1695 Scope ID Last Address TTL Name Name Lang Language 1696 Count Flags Length Tag 1697 +---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+... 1698 |224| 0 | 1 | 0 |238|255|255|255|16 | 1 | 128 | 2 | en | 1699 +---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+... 1701 Name 1702 Length Name 1703 +------+--...--+ 1704 | 5 | world | 1705 +------+--...--+ 1707 3.11. List of Address Ranges 1709 This option is used by the server to provide the list of all the 1710 address ranges allocated to the client. 1712 This option is also used by the client when requesting a lease for a 1713 specific set of addresses. This feature should be needed only rarely, 1714 such as when a lease is accidentally allowed to expire and it needs 1715 to be reallocated. 1717 The address family of the addresses is determined by the addrfamily 1718 field. 1720 The code for this option is 10 and the minimum length is 0. 1722 Code Len Address Range List 1723 +-----+-----+-----+-----+-----+-----+-...-+-----+ 1724 | 10 | n | L1 | L2 | | Ln | 1725 +-----+-----+-----+-----+-----+-----+-...-+-----+ 1727 where the Address Range List is of the following format. 1729 StartAddress1 BlockSize1 StartAddress2 BlockSize2 ... 1730 +---+---+---+---+---+---+---+---+---+---+---+---+--...--+ 1731 | ... S1 ... |B11|B12| ... S2 ... |B21|B22| | 1732 +---+---+---+---+---+---+---+---+---+---+---+---+--...--+ 1734 3.12. Current Time 1736 This option is used to express what the sender thinks the current 1737 time is. This is useful for detecting clock skew. This option MUST be 1738 included if the Start Time or Maximum Start Time options are used, as 1739 described in section 2.12. 1741 The time value is an unsigned 32 bit integer in network byte order 1742 giving the number of seconds since 00:00 UTC, 1st January 1970. This 1743 can be converted to an NTP [4] timestamp by adding decimal 1744 2208988800. This time format will not wrap until the year 2106. 1746 The code for this option is 11 and the length is 4. 1748 Code Len Time 1749 +-----+-----+-----+-----+-----+-----+-----+-----+ 1750 | 11 | 4 | t1 | t2 | t3 | t4 | 1751 +-----+-----+-----+-----+-----+-----+-----+-----+ 1753 3.13. Feature List 1755 This option lists optional MADCAP features supported, requested, or 1756 required, by the sender. This option MAY be included in any message 1757 sent by a MADCAP server or client. 1759 Optional features of MADCAP are identified with a two octet feature 1760 code. New MADCAP feature codes may only be defined by IETF 1761 Consensus, as described in section 5. 1763 The Feature List option consists of three separate lists: supported 1764 features, requested features, and required features. Each list 1765 consists of an unordered list of feature codes. The supported list is 1766 used by MADCAP clients or servers to indicate the features that the 1767 sender supports. The requested and required lists are used by MADCAP 1768 clients to indicate which features are requested of or required from 1769 a MADCAP server. The required list is used by MADCAP servers to 1770 indicate which features were implemented by the MADCAP server in 1771 processing this message. Messages sent by MADCAP servers MUST NOT 1772 include any feature codes in the requested list. 1774 If a MADCAP client includes the Feature List option in a message, it 1775 MAY include features in any of the lists: supported, requested, and 1776 required. If a MADCAP server receives a message containing the 1777 Feature List option and it does not support all of the features in 1778 the required list, it MUST generate and process a Required Feature 1779 Not Supported error in the manner described in section 2.6. If the 1780 server supports all of the features in the required list, it MUST 1781 implement them as appropriate for this message. It SHOULD try to 1782 implement the features in the requested list and it MAY implement any 1783 of the features in the supported list. If an optional feature (such 1784 as Retry After) is not included in any part of the Feature List 1785 option included in the client's message (or if the client does not 1786 include a Feature List option in its message), the server MUST NOT 1787 use that feature in its response. 1789 If a MADCAP server does respond to a client's message that includes a 1790 Feature List option, the server MUST include a Feature List option 1791 with a supported features list that lists the features that it 1792 supports, a required features list that lists the features that it 1793 implemented in responding to this message (which must be included in 1794 the supported features list of the client's Feature List option), and 1795 an empty requested features list. 1797 The code for this option is 12 and the minimum length is 6. 1799 Code Len Supported Requested Required 1800 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 1801 | 12 | n | FL1 | FL2 | FL3 | 1802 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 1804 where each of the Feature Lists is of the following format: 1806 Feature Feature Feature 1807 Count Code 1 Code m 1808 +-----+-----+-----+-----+-...-+-----+-----+ 1809 | m | FC1 | | FCm | 1810 +-----+-----+-----+-----+-...-+-----+-----+ 1812 3.14. Retry Time 1813 The Retry Time option specifies the time at which a client should 1814 retry a REQUEST or RENEW message when using the Retry After feature. 1816 This option should only be sent by a MADCAP server in an ACK when 1817 responding to a REQUEST or RENEW message that includes the Retry 1818 After feature in the supported, requested, or required list. For more 1819 discussion of Retry After, see section 2.13.2. 1821 If the Retry Time option is present, the Current Time option MUST 1822 also be present. 1824 The time value is an unsigned 32 bit integer in network byte order 1825 giving the number of seconds since 00:00 UTC, 1st January 1970. This 1826 can be converted to an NTP timestamp by adding decimal 2208988800. 1827 This time format will not wrap until the year 2106. 1829 The code for this option is 13 and the length is 4. 1831 Code Len Time 1832 +-----+-----+-----+-----+-----+-----+-----+-----+ 1833 | 13 | 4 | t1 | t2 | t3 | t4 | 1834 +-----+-----+-----+-----+-----+-----+-----+-----+ 1836 3.15. Minimum Lease Time 1838 This option is used in a client request (DISCOVER, REQUEST, or RENEW) 1839 to allow the client to specify a minimum lease time for the multicast 1840 address. If a server cannot meet this minimum lease time, it MUST 1841 generate and process a Valid Request Could Not Be Completed error in 1842 the manner described in section 2.6. 1844 The time is in units of seconds, and is specified as a 32-bit 1845 unsigned integer. 1847 The code for this option is 14, and its length is 4. 1849 Code Len Lease Time 1850 +-----+-----+-----+-----+-----+-----+-----+-----+ 1851 | 14 | 4 | t1 | t2 | t3 | t4 | 1852 +-----+-----+-----+-----+-----+-----+-----+-----+ 1854 3.16. Maximum Start Time 1856 The Maximum Start Time option specifies the latest starting time that 1857 the client is willing to accept for a multicast address lease. 1859 A client may include this option in a DISCOVER, RENEW, or REQUEST 1860 message to specify that it does not want to receive a lease with a 1861 starting time later than the specified value. If a server cannot meet 1862 this maximum start time, it MUST generate and process a Valid Request 1863 Could Not Be Completed error in the manner described in section 2.6. 1865 If the Maximum Start Time option is present, the Current Time option 1866 MUST also be present, as described in section 2.12. 1868 The time value is an unsigned 32 bit integer in network byte order 1869 giving the number of seconds since 00:00 UTC, 1st January 1970. This 1870 can be converted to an NTP timestamp by adding decimal 2208988800. 1871 This time format will not wrap until the year 2106. 1873 The code for this option is 15 and the length is 4. 1875 Code Len Time 1876 +-----+-----+-----+-----+-----+-----+-----+-----+ 1877 | 15 | 4 | t1 | t2 | t3 | t4 | 1878 +-----+-----+-----+-----+-----+-----+-----+-----+ 1880 3.17. Error 1882 A MADCAP server includes this option in a NAK message to indicate why 1883 the request failed. A MADCAP server MUST include an Error option in 1884 each NAK message. 1886 The first two octets of an Error option contain a MADCAP error code. 1887 Several MADCAP error codes are defined later in this section. New 1888 MADCAP error codes may only be defined by IETF Consensus, as 1889 described in section 5. 1891 Any remaining octets in the Error option contain extra data about the 1892 error. The format of this data depends on the error code. The 1893 definition of a MADCAP error code must include a definition of the 1894 extra data to be included with that error code. 1896 A client that receives a NAK message containing an Error option MAY 1897 log or display a message indicating the error code and extra data 1898 received. The client MUST NOT retransmit a message once a NAK 1899 response to that message has been received. The client MAY adjust the 1900 message to correct the error and send the corrected message or send a 1901 message to a different server. 1903 The code for this option is 16, and the minimum length is 2. 1905 Code Len Error Code Extra Data 1906 +-----+-----+-----+-----+-----+-----+-----+-----+ ... 1907 | 16 | n | ecode | d1 d2 1908 +-----+-----+-----+-----+-----+-----+-----+-----+ ... 1910 3.17.1. Valid Request Could Not Be Completed 1912 MADCAP error code 0 indicates that the request was valid, but could 1913 not be completed with the available addresses and the current 1914 configuration. The extra data is a two octet option code indicating 1915 which option caused the problem. A value of 0xFFFF indicates that the 1916 problem was not with a specific option. 1918 3.17.2. Invalid Request 1920 MADCAP error code 1 indicates that the request was malformed or 1921 invalid in some other manner. The extra data is a two octet option 1922 code indicating which option caused the problem. A value of 0xFFFF 1923 indicates that the problem was not with a specific option. 1925 3.17.3. Excessive Clock Skew 1927 MADCAP error code 2 indicates excessive clock skew (see section 1928 2.12). The extra data consists of a four octet time value 1929 representing the server's idea of the current time, an unsigned 32 1930 bit integer in network byte order giving the number of seconds since 1931 00:00 UTC, 1st January 1970. This can be converted to an NTP 1932 timestamp by adding decimal 2208988800. This time format will not 1933 wrap until the year 2106. 1935 3.17.4. Lease Identifier Not Recognized 1937 MADCAP error code 3 indicates that the Lease Identifier was not 1938 recognized (usually in response to a RENEW or RELEASE message). There 1939 is no extra data. 1941 3.17.5. Required Feature Not Supported 1943 MADCAP error code 4 indicates that at least one feature included in 1944 the required list of the Feature List option is not supported. The 1945 extra data contains a list of the feature codes in the required list 1946 that are not supported. 1948 3.17.6. Experimental Use 1950 MADCAP error codes 1024-2047 are reserved for experimental use. The 1951 format of the extra data included with these error codes is not 1952 defined. 1954 4. Security Considerations 1956 MADCAP has relatively basic security requirements. At present there 1957 is no way of enforcing authorized use of multicast addresses in the 1958 multicast routing/management protocols. Therefore, it is not 1959 possible to identify unauthorized use of multicast address by an 1960 adversary. Moreover, a multicast address allocated to a user/system 1961 can be used by other systems without violating terms of the multicast 1962 address allocation. For example, a system may reserve an address to 1963 be used for a work group session where each and every member of the 1964 work group is allowed to transmit packets using the allocated group 1965 address. In other words, the multicast address allocation protocol 1966 does not dictate how the address should be used, it only dictates the 1967 time period for which it can be used and who gets to release it or 1968 renew it. When an address is allocated to a system/user, it basically 1969 means that no other user/system (most likely) will be allocated that 1970 address for the time period, without any restrictions on its use. 1972 To protect against rogue MADCAP servers (mis-configured servers and 1973 intentional), clients in certain situations would like to 1974 authenticate the server. Similarly, for auditing or book-keeping 1975 purposes, the server may want to authenticate clients. Moreover, in 1976 some cases, the server may have certain policies in place to restrict 1977 the number of addresses that are allocated to a system or a user. 1978 This feature is of much value when a well behaved but naive user or 1979 client requests a large number of addresses, and therefore, 1980 inadvertently impacts other users or systems. Therefore, an 1981 administrator may want to exert a limited amount of control based on 1982 the client identification. The client identification could be based 1983 on the system or user identity. In most practical situations, system 1984 identification will suffice, however, particularly in case of 1985 multi-user systems, at times, user identification will play an 1986 important role. Therefore, authentication capabilities based on user 1987 identification may be desirable. As usual, data integrity is a strong 1988 requirement and if not protected, can lead to many problems including 1989 denial of service attacks. 1991 In the case of MADCAP, confidentiality is not a strong requirement. 1992 In most of the cases, at least when a multicast address is in use, an 1993 adversary will be able to determine information that was contained in 1994 the MADCAP messages. In some cases, the users/systems may want to 1995 protect information in the MADCAP messages so that an adversary is 1996 not able to determine relevant information in advance and thus, plan 1997 an attack in advance. For example, if an adversary knows in advance 1998 (based on MADCAP messages) that a particular user has requested a 1999 large number of address for certain time period and scope, he may be 2000 able to guess the purpose behind such request and target an attack. 2001 When the Shared Lease Identifier feature is used, preserving the 2002 confidentiality of MADCAP messages becomes more important. Also, 2003 there may be features added to the protocol in the future that may 2004 have stronger confidentiality requirements. 2006 The IPSEC protocol [8] meets client/server identification and 2007 integrity protection requirements stated above, requires no 2008 modification to the MADCAP protocol, and leverages extensive work in 2009 IETF and industry. Therefore, when security is a strong requirement, 2010 IPSEC SHOULD be used for protecting all the unicast messages of 2011 MADCAP protocol. When IPSEC based security is in use, all the 2012 multicast packets except GETINFO MUST be dropped by the MADCAP 2013 server. The prevalent implementations of IPSEC support client 2014 identification in form of system identification and do not support 2015 user identification. However, when desired, IPSEC with appropriate 2016 API's may be required to support user identification. 2018 5. IANA Considerations 2020 This document defines several number spaces (MADCAP options, MADCAP 2021 message types, MADCAP Lease Identifier types, MADCAP features, and 2022 MADCAP error codes). For all of these number spaces, certain values 2023 are defined in this specification. New values may only be defined by 2024 IETF Consensus, as described in [7]. Basically, this means that they 2025 are defined by RFCs approved by the IESG. 2027 6. Acknowledgments 2029 The authors would like to thank Rajeev Byrisetty, Steve Deering, 2030 Peter Ford, Mark Handley, Van Jacobson, David Oran, Thomas Pfenning, 2031 Dave Thaler, Ramesh Vyaghrapuri and the participants of the IETF for 2032 their assistance with this protocol. 2034 Much of this document is based on [1] and [2]. The authors of this 2035 document would like to express their gratitude to the authors of 2036 these previous works. Any errors in this document are solely the 2037 fault of the authors of this document. 2039 7. References 2041 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 2042 March 1997. 2044 [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor 2045 Extensions", RFC 2132, March 1997. 2047 [3] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, 2048 July 1998. 2050 [4] Mills, D., "Network Time Protocol (Version 3) Specification, 2051 Implementation and Analysis", RFC 1305, March 1992. 2053 [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2054 2279, January 1998. 2056 [6] Alvestrand, H., "Tags for the Identification of Languages", RFC 2057 1766, March 1995. 2059 [7] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 2060 Considerations Section in RFCs", RFC 2434, October 1998. 2062 [8] Atkinson, R. and S. Kent, "Security Architecture for the Internet 2063 Protocol", RFC 2401, November 1998. 2065 [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2066 Levels", RFC 2119, March 1997. 2068 [10] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. 2070 [11] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 2071 August 1989. 2073 [12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 2074 Specification", RFC 2460, December 1998. 2076 [13] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", 2077 RFC 2373, July 1998. 2079 [14] Schulzrinne, H., S. Casner, R. Frederick, V. Jacobson, "RTP: 2080 A Transport Protocol for Real-Time Applications", RFC 1889, 2081 January 1996. 2083 8. Authors' Addresses 2085 Stephen R. Hanna 2086 Sun Microsystems, Inc. 2087 One Network Drive 2088 Burlington, MA 01803 2090 Phone: +1.781.442.0166 2091 Email: steve.hanna@sun.com 2093 Baiju V. Patel 2094 Intel Corp. 2095 Mail Stop: AG2-201 2096 5200 NE Elam Young Parkway 2097 Hillsboro, OR 97124 2099 Phone: 503 696 8192 2100 EMail: baiju.v.patel@intel.com 2101 Munil Shah 2102 Microsoft Corporation 2103 One Microsoft Way 2104 Redmond, WA 98052 2106 Phone: 425 703 3924 2107 Email: munils@microsoft.com 2109 APPENDIX A: Examples 2111 This appendix includes several examples of typical MADCAP protocol 2112 exchanges. 2114 1. Multicast Scope List Discovery 2116 In this example, a MADCAP client wants to determine the scope list in 2117 effect. The client is using IPv4, so it starts by multicasting an 2118 GETINFO packet to the MADCAP Server Multicast Address corresponding 2119 to IPv4 Local Scope. This packet includes the Lease Identifier 2120 option, an Option Request List including the Multicast Scope List 2121 option code, and a Requested Language option containing the string 2122 "en", since the client is configured to prefer the English language. 2124 Two MADCAP servers respond by sending ACK messages. These ACK 2125 messages include the Lease Identifier option and xid supplied by the 2126 client, the server's Server Identifier, and the Multicast Scope List 2127 with one name per scope (the one that most closely matches the 2128 language tag "en"). 2130 The following figure illustrates this exchange. 2132 Server Client Server 2133 v v v 2134 | | | 2135 | | | 2136 | _____________/|\_____________ | 2137 |/ GETINFO | GETINFO \| 2138 | | | 2139 | | | 2140 |\ | ____________/| 2141 | \_________ | / ACK | 2142 | ACK \ |/ | 2143 | \ | | 2144 | | | 2145 v v v 2147 Figure 2: Timeline diagram of messages exchanged 2148 in Multicast Scope List Discovery example 2150 2. Multicast Discovery and Address Allocation 2152 In this example, the MADCAP client wants to allocate a multicast 2153 address from the global scope for use during the next two hours. 2155 The client begins by multicasting a DISCOVER packet to the MADCAP 2156 Server Multicast Address associated with IPv4 Local Scope. This 2157 packet includes the Lease Time, Lease Identifier, and Multicast Scope 2158 options. 2160 Any servers that receive the DISCOVER packet and can satisfy this 2161 request temporarily reserve an address for the client and unicast an 2162 OFFER packet to the client. These packets contain the Lease Time, 2163 Server Identifier, Lease Identifier, and Multicast Scope options. 2165 After an appropriate delay, the client multicasts a REQUEST packet to 2166 the MADCAP Server Multicast Address. This packet contains all of the 2167 options included in the DISCOVER packet, but also includes the Server 2168 Identifier option, indicating which server it has selected for the 2169 request. 2171 The server whose Server Identifier matches the one specified by the 2172 client responds with an ACK packet containing the options included in 2173 the OFFER packet, as well as a List of Address Ranges option listing 2174 the address allocated. All the other servers that had sent OFFER 2175 packets stop reserving an address for the client and forget about the 2176 whole exchange. 2178 The client now has a two hour "lease" on the multicast address. 2180 If the client had not received an ACK from the server, it would have 2181 retransmitted its REQUEST packet for a while. If it still received no 2182 response, it would start over with a new DISCOVER message. 2184 The following figure illustrates this exchange. 2186 Server Client Server 2187 (not selected) (selected) 2188 v v v 2189 | | | 2190 |Begin multicast address request| 2191 | | | 2192 | _____________/|\_____________ | 2193 |/ DISCOVER | DISCOVER \| 2194 | | | 2195 Reserves | Reserves 2196 Address | Address 2197 | | | 2198 |\ | ____________/| 2199 | \_________ | / OFFER | 2200 | OFFER \ |/ | 2201 | \ | | 2202 | Collects replies | 2203 | \| | 2204 | Selects Server | 2205 | | | 2206 | _____________/|\_____________ | 2207 |/ REQUEST | REQUEST \| 2208 | | | 2209 | | Commits address 2210 | | | 2211 | | _____________/| 2212 | |/ ACK | 2213 | | | 2214 | assignment complete | 2215 | | | 2216 v v v 2218 Figure 3: Timeline diagram of messages exchanged 2219 in Multicast Address Allocation example 2221 3. Lease Extension 2223 This is a continuation of the previous example. The client has 2224 already allocated a multicast address from the global scope for use 2225 during the next two hours. Half way through this two hour period, it 2226 decides that it wants to extend its lease for another hour. 2228 The client unicasts a RENEW packet to the server from which it 2229 allocated the address. This packet includes the Lease Time and Lease 2230 Identifier options. The Lease Identifier matches the one used for the 2231 original allocation. The time included in the Lease Time is two 2232 hours, since the client wants the lease to expire two hours from the 2233 current time. 2235 The server responds with an ACK packet indicating that the lease 2236 extension has been granted. This packet includes the Lease Time, 2237 Server Identifier, Lease Identifier, Multicast Scope, and List of 2238 Address Ranges options. 2240 If the server did not want to grant the requested lease extension, it 2241 would have responded with a NAK packet with the Lease Identifier 2242 option. 2244 The following figure illustrates this exchange. 2246 Client Server 2247 v v 2248 | | 2249 |\_____________ | 2250 | RENEW \| 2251 | | 2252 | Extends lease 2253 | | 2254 | _____________/| 2255 |/ ACK | 2256 | | 2257 | | 2258 v v 2260 Figure 4: Timeline diagram of messages exchanged 2261 in Lease Extension example 2263 4. Address Release 2265 This is a continuation of the previous example. The client has 2266 already allocated a multicast address and extended its lease for 2267 another two hours. Half an hour later, the client finishes its use of 2268 the multicast address and wants to release it so it can be reused. 2270 The client unicasts a RELEASE packet to the server from which it 2271 allocated the address. This packet includes the Lease Identifier 2272 option. The Lease Identifier matches the one used for the original 2273 allocation. When the server receives this packet, it cancels the 2274 client's lease on the address and sends an ACK packet to the client 2275 indicating that the lease has been released. This packet includes the 2276 Server Identifier and Lease Identifier options. 2278 The following figure illustrates this exchange. 2280 Client Server 2281 v v 2282 | | 2283 |\_____________ | 2284 | RELEASE \| 2285 | | 2286 | Cancels lease 2287 | | 2288 | _____________/| 2289 |/ ACK | 2290 | | 2291 v v 2293 Figure 5: Timeline diagram of messages exchanged 2294 in Address Release example 2296 5. Unicast Address Allocation 2298 This is a continuation of the previous example. At some later time, 2299 the client decides to allocate another multicast address. Since it 2300 has recently worked with a server, it decides to try sending a 2301 unicast REQUEST to that server. If this doesn't work, it can always 2302 try a multicast DISCOVER, as illustrated in example 2. 2304 The client unicasts a REQUEST packet to the server from which it 2305 wants to allocate the address. This packet includes the Lease Time, 2306 Lease Identifier, and Multicast Scope options. 2308 The server responds with an ACK packet containing the Lease Time, 2309 Lease Identifier, and Multicast Scope options from the REQUEST 2310 packet, as well as the Server Identifier option and a List of Address 2311 Ranges option listing the address allocated. 2313 The client now has a lease on the multicast address. 2315 If the client had not received an ACK from the server, it would have 2316 retransmitted its REQUEST packet for a while. If it still received no 2317 response, it would start over with a multicast DISCOVER message. 2319 The following figure illustrates this exchange. 2321 Client Server 2322 v v 2323 | | 2324 |\_____________ | 2325 | REQUEST \| 2326 | | 2327 | Allocates address 2328 | | 2329 | _____________/| 2330 |/ ACK | 2331 | | 2332 v v 2334 Figure 6: Timeline diagram of messages exchanged 2335 in Unicast Address Allocation example 2337 APPENDIX B: Recommended Constant Values 2339 Table 6 lists recommended values for constants defined in this 2340 specification. 2342 Constant Name Recommended Value 2343 ------------- ----------------- 2344 [CLOCK-SKEW-ALLOWANCE] 30 minutes 2345 [DISCOVER-DELAY] current retransmit delay 2346 [EXTRA-ALLOCATION-TIME] 1 hour 2347 [NO-RESPONSE-DELAY] 60 seconds 2348 [OFFER-HOLD] at least 60 seconds 2349 [RESPONSE-CACHE-INTERVAL] at least 60 seconds (5 minutes maximum) 2350 [XID-REUSE-INTERVAL] 10 minutes (required) 2352 Table 6: Recommended Constant Values