idnits 2.17.1 draft-ietf-malloc-madcap-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 48 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 6 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 2268 -- Looks like a reference, but probably isn't: 'RESPONSE-CACHE-INTERVAL' on line 2267 -- Looks like a reference, but probably isn't: 'DISCOVER-DELAY' on line 2263 -- Looks like a reference, but probably isn't: 'OFFER-HOLD' on line 2266 -- Looks like a reference, but probably isn't: 'NO-RESPONSE-DELAY' on line 2265 -- Looks like a reference, but probably isn't: 'EXTRA-ALLOCATION-TIME' on line 2264 -- Looks like a reference, but probably isn't: 'CLOCK-SKEW-ALLOWANCE' on line 2262 ** 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) 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 May 1999 Munil Shah, Microsoft Corp. 4 Expires: November 1999 draft-ietf-malloc-madcap-05.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 first address in a multicast scope. This definition applies 80 only within this document. 82 Scope Zone 83 A single multicast scope may have several instances, which are 84 known as 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. Each zone may have 97 several names, each in a different language. 99 Multicast Scope List 100 A list of multicast scope zones. 102 Since it can be difficult to determine which multicast scope zones 103 are in effect, MADCAP clients can ask MADCAP servers to supply a 104 Multicast Scope List listing all of the zones available to the 105 client. For each scope zone, the list includes the range of 106 multicast addresses for this scope, a maximum TTL or hop count to 107 be used for this scope, and one or more zone names for this scope 108 zone. 110 This definition applies only within this document. 112 1.3. Motivation and Protocol Requirements 114 For multicast applications to be deployed everywhere, there is a need 115 to define a protocol that any host may use to allocate multicast 116 addresses. Here are the requirements for such a protocol. 118 Quick response: The host should be able to allocate a multicast 119 address and begin to use it promptly. 121 Low network load: Hosts that are not allocating or deallocating 122 multicast addresses at the present time should not need to send or 123 receive any network traffic. 125 Support for intermittently connected or power managed systems: Hosts 126 should be able to be disconnected from the network, powered off, or 127 otherwise inaccessible except during the brief period during which 128 they are allocating a multicast address. 130 Multicast address scopes: The protocol must be able to allocate both 131 the administratively scoped and globally scoped multicast addresses. 133 Efficient use of address space: The multicast address space is fairly 134 small. The protocol should make efficient use of this scarce 135 resource. 137 Authentication: Because multicast addresses are scarce, it is 138 important to protect against hoarding of these addresses. One way to 139 do this is by authenticating clients. This is also a key prerequisite 140 for establishing policies. 142 Policy neutral: Allocation policies (such as who can allocate 143 addresses) should not be dictated by the protocol. 145 1.4. Relationship with DHCP 147 MADCAP was originally based on DHCP. There are still some 148 similarities and it may be possible to share some code between a DHCP 149 implementation and a MADCAP implementation. However, MADCAP is 150 completely separate from DHCP, with no dependencies between the two 151 and many significant differences. 153 1.5. Protocol Overview 155 MADCAP is built on a client-server model, where hosts request address 156 allocation services from address allocation servers. When a MADCAP 157 client wishes to request a service, it unicasts or multicasts a 158 message to one or more MADCAP servers, each of which optionally 159 responds with a message unicast to the client. 161 All messages are UDP datagrams. The UDP data contains a fixed length 162 header and a variable length options field. Options are encoded in a 163 type-length-value format with two octets type and value fields. The 164 fixed fields are version, msgtype (message type), addrfamily (address 165 family), and xid (transaction identifier). 167 Retransmission is handled by the client. If a client sends a message 168 and does not receive a response, it may retransmit its request a few 169 times using an exponential backoff. To avoid executing the same 170 client request twice when a retransmitted request is received, 171 servers cache responses for a short period of time and resend cached 172 responses upon receiving retransmitted requests. 174 Each request contains a msgtype, an xid, and a Lease Identifier 175 option. Clients must ensure that this triple is probably unique 176 across all MADCAP messages received by a MADCAP server over a period 177 of [XID-REUSE-INTERVAL] (10 minutes). This allows the MADCAP server 178 to use this triple as the key in its response cache. 180 Messages sent by servers include the xid included in the original 181 request so that clients can match up responses with requests. 183 The msgtype field is a single octet that defines the "type" of a 184 MADCAP message. Currently defined message types are listed in Table 185 2. They are: DISCOVER, OFFER, REQUEST, RENEW, ACK, NAK, RELEASE, and 186 INFORM. DISCOVER, REQUEST, RENEW, RELEASE, and INFORM messages are 187 only sent by a client. OFFER, ACK, and NAK messages are only sent by 188 a server. 190 The REQUEST, RENEW, and RELEASE messages are used to request, renew, 191 or release a lease on one or more multicast addresses. A client 192 unicasts one of these messages to a server and the server responds 193 with an ACK or a NAK. 195 The INFORM message is used to request information, such as the 196 multicast scope list, or to find MADCAP servers. A client may unicast 197 an INFORM message to a MADCAP server. However, it may not know the IP 198 address of any MADCAP server. In that case, it will multicast an 199 INFORM message to a MADCAP Server Multicast Address and all servers 200 that wish to respond will send a unicast ACK or NAK back to the 201 client. 203 Each multicast scope has an associated MADCAP Server Multicast 204 Address. This address has been reserved by the IANA as the address 205 with a relative offset of -1 from the last address of a multicast 206 scope. MADCAP clients use this address to find MADCAP servers. 208 The DISCOVER message is a message used to discover MADCAP servers 209 that can probably satisfy a REQUEST. DISCOVER messages are always 210 multicast. Servers that can probably satisfy a REQUEST corresponding 211 to the parameters supplied in the DISCOVER message temporarily 212 reserve the addresses needed and send a unicast OFFER back to the 213 client. The client selects a server with which to continue and sends 214 a multicast REQUEST including the server's Server Identifier to the 215 same multicast address used for the DISCOVER. The chosen server 216 responds with an ACK or NAK and the other servers stop reserving the 217 addresses they were temporarily holding. 219 For detailed descriptions of typical protocol exchanges, consult 220 Appendix A. 222 MADCAP is a mechanism rather than a policy. MADCAP allows local 223 system administrators to exercise control over configuration 224 parameters where desired. For example, MADCAP servers may be 225 configured to limit the number of multicast addresses allocated to a 226 single client. Properly enforcing such a limit requires cryptographic 227 security, as described in the Security Consideration section. 229 2. Protocol Description 231 The MADCAP protocol is a client-server protocol. In general, the 232 client unicasts or multicasts a message to one or more servers, which 233 optionally respond with messages unicast to the client. 235 A reserved port number dedicated for MADCAP is used on the server 236 (port number 2535, as assigned by IANA). Any port number may be used 237 on client machines. When a MADCAP server sends a message to a MADCAP 238 client, it MUST use a destination port number that matches the source 239 port number provided by the client in the message that caused the 240 server to send its message. 242 The next few sections describe the MADCAP message format and message 243 types. A full list of MADCAP options is provided in section 3. 245 2.1. Message Format 247 Figure 1 gives the format of a MADCAP message and Table 1 describes 248 each of the fields in the MADCAP message. The numbers in parentheses 249 indicate the size of each field in octets. The names for the fields 250 given in the figure will be used throughout this document to refer to 251 the fields in MADCAP messages. 253 All multi-octet quantities are in network byte-order. 255 Any message whose UDP data is too short to hold this format (at least 256 12 bytes) MUST be ignored. 258 +-+-+-+-+-+-+-+-+ 259 | version (1) | 260 +---------------+ 261 | msgtype (1) | 262 +---------------+ 263 | addrfamily | 264 | (2) | 265 +---------------+ 266 | | 267 | xid (4) | 268 | | 269 | | 270 +---------------+ 271 | | 272 | options | 273 | (variable) | 274 | ... | 275 +---------------+ 277 Figure 1: Format of a MADCAP message 279 FIELD OCTETS DESCRIPTION 280 ----- ------ ----------- 282 version 1 Protocol version number (zero for this specification) 283 msgtype 1 Message type (DISCOVER, INFORM, etc.) 284 addrfamily 2 Address family (IPv4, IPv6, etc.) 285 xid 4 Transaction ID 286 options var Options field 288 Table 1: Description of fields in a MADCAP message 290 2.1.1. The version field 292 The version field must always be zero for this version of the 293 protocol. Any messages that include other values in this field MUST 294 be ignored. 296 2.1.2. The msgtype field 298 The msgtype field defines the "type" of the MADCAP message. 300 For more information about this field, see section 2.2. 302 2.1.3. The addrfamily field 304 The addrfamily field defines the default address family (such as IPv4 305 or IPv6) for this MADCAP message, using the address family numbers 306 defined in by the IANA (including those defined in [10]). Unless 307 otherwise specified, all addresses included in the message will be 308 from this family. 310 2.1.4. The xid field 312 The xid field is a transaction identifier. This is a number chosen by 313 the client so that the combination of xid, msgtype, and Lease 314 Identifier is probably unique across all MADCAP messages received by 315 a MADCAP server over a period of [XID-REUSE-INTERVAL] (10 minutes). 317 The xid field is used by the client and server to associate messages 318 and responses between a client and a server. Before a client sends a 319 message, it chooses a number to use as an xid. The technique used to 320 choose an xid is implementation-dependent, but whatever technique is 321 used SHOULD make it unlikely that the same combination of xid, 322 msgtype, and Lease Identifier will be used for two different messages 323 within [XID-REUSE-INTERVAL] (even across multiple clients which do 324 not communicate among themselves). This allows enough time for the 325 message to be dropped from all server response caches (as described 326 in the next few paragraphs) and for any network delays to be 327 accomodated. The RECOMMENDED technique for choosing an xid is to 328 choose a random four octet number as the first xid in a session and 329 increment this value each time a new xid is needed. 331 When a server responds to a client message, it MUST use the same xid 332 value in the response that the client used in the request. This 333 allows the client to associate responses with the message that they 334 are responding to. 336 When retransmitting messages (as described in section 2.3), the 337 client MUST retransmit them without changing them, thereby using the 338 same xid and and Lease Identifier. 340 If a server receives a message with the same xid, msgtype, and Lease 341 Identifier as one received within [RESPONSE-CACHE-INTERVAL], it 342 SHOULD treat this message as a retransmission of the previously 343 received one and retransmit the response, if any. After [RESPONSE- 344 CACHE-INTERVAL], the server may forget about the previously received 345 message and treat any retransmissions of this message as if they were 346 new messages. Of course, a server need not cache a message if it ends 347 up ignoring that message. However, performance gains may be achieved 348 by doing so. 350 This avoids retransmissions causing multiple allocations. An 351 appropriate value for [RESPONSE-CACHE-INTERVAL] would be sixty 352 seconds, but it may have any value from zero seconds to 300 seconds 353 (five minutes) and may be adjusted dynamically according to resource 354 constraints on the server. 356 2.1.5. The options field 358 The options field consists of a list of tagged parameters that are 359 called "options". All options consist of a two octet option code and 360 a two octet option length, followed by the number of octets specified 361 by the option length. In the case of some options, the length field 362 is a constant but must still be specified. 364 The option field MUST contain a sequence of options with the last one 365 being the End option (option code 0). Any message whose options field 366 does not conform to this syntax MUST be ignored. 368 Any MADCAP client or server sending a MADCAP message MAY include any 369 of the options listed in section 3, subject to the restrictions in 370 Table 5 and elsewhere in this document. They MAY also include other 371 MADCAP options that are defined in the future. A MADCAP client or 372 server MUST NOT include more than one option with the same option 373 type in one MADCAP message. 375 All MADCAP clients and servers MUST recognize all options listed in 376 this document and behave in accordance with this document when 377 receiving and processing any of these options. Any unrecognized 378 options MUST be ignored. If a MADCAP server receives a message that 379 does not conform to the requirements of this document (for instance, 380 not including all required options), an Invalid Request error MUST be 381 generated and processed in the manner described in section 2.6. If a 382 MADCAP client receives a message that does not conform to the 383 requirements of this document, it MUST ignore the message. 385 The order of options within a message has no significance and any 386 order MUST be supported in an equivalent manner, with the exception 387 that the End option must occur once per message, as the last option 388 in the option field. 390 New MADCAP option codes may only be defined by IETF Consensus, as 391 described in section 5. 393 2.2. Message Types 395 The msgtype field defines the "type" of a MADCAP message. Legal 396 values for this field are: 398 Value Message Type 399 ----- ------------ 400 1 DISCOVER 401 2 OFFER 402 3 REQUEST 403 4 RENEW 404 5 ACK 405 6 NAK 406 7 RELEASE 407 8 INFORM 409 Table 2: MADCAP message types 411 Throughout this document, MADCAP messages will be referred to by the 412 type of the message; e.g., a MADCAP message with a message type of 8 413 will be referred to as an INFORM message. 415 Here are descriptions of the MADCAP message types. Table 5, which 416 appears at the beginning of section 3, summarizes which options are 417 allowed with each message type. 419 MADCAP clients and servers MUST handle all MADCAP message types 420 defined in this document in a manner consistent with this document. 422 If a MADCAP server receives a message whose message type it does not 423 recognize, an Invalid Request error MUST be generated and processed 424 in the manner described in section 2.6. If a MADCAP client receives a 425 message whose message type it does not recognize, it MUST ignore the 426 message. 428 Note, however, that under some circumstances this document requires 429 or suggests that clients or servers ignore messages with certain 430 message types even though they may be recognized. For instance, 431 clients that do not send DISCOVER messages SHOULD ignore OFFER 432 messages. Also, secure servers SHOULD ignore DISCOVER messages and 433 all servers SHOULD ignore DISCOVER messages that they cannot satisfy. 435 New MADCAP message types may only be defined by IETF Consensus, as 436 described in section 5. 438 2.2.1. INFORM 440 The INFORM message is used by a MADCAP client that wants to acquire 441 configuration parameters, especially a multicast scope list. This 442 message also allows a client to determine which servers are likely to 443 be able to handle future requests. 445 The MADCAP client sends out an INFORM message. The message may be 446 unicast to a particular MADCAP server or multicast to a MADCAP Server 447 Multicast Address. For more details about the MADCAP Server Multicast 448 Address, see section 2.10. 450 If a server receives an INFORM message and it can process the request 451 successfully, it MUST unicast an ACK message to the client. All 452 INFORM messages MUST include an Option Request List option. The 453 server SHOULD try to include the specified options in its response, 454 but is not required to do so (especially if it does not recognize 455 them). 457 If a server receives an INFORM message and it does not process the 458 request successfully, it MUST generate and process an error in the 459 manner described in section 2.6. 461 If a client sends an INFORM message and does not receive any ACK 462 messages in response, it SHOULD resend its INFORM message, as 463 described in section 2.3. 465 When a MADCAP client sends an INFORM message, it MAY include the 466 Requested Language option, which specifies which language the client 467 would prefer for the zone names in the Multicast Scope List. The 468 proper way to handle this tag with respect to zone names is discussed 469 in the definition of the Multicast Scope List option. 471 2.2.2. DISCOVER 473 The DISCOVER message is a multicast message sent by a MADCAP client 474 that wants to discover MADCAP servers that can probably satisfy a 475 REQUEST. 477 MADCAP clients are not required to use the DISCOVER message. They 478 MAY employ other methods to find MADCAP servers, such as sending a 479 multicast INFORM message, caching an IP address that worked in the 480 past or being configured with an IP address. Using the DISCOVER 481 message has the particular advantage that it allows clients to 482 receive responses from all servers that can satisfy the request. 484 The MADCAP client begins by sending a multicast DISCOVER message to a 485 MADCAP Server Multicast Address. Any servers that wish to assist the 486 client respond by sending a unicast OFFER message to the client. If a 487 server can process the request with a shorter lease time or later 488 start time than the client requested, it SHOULD send an OFFER message 489 with the lease time or start time that it can offer. However, it 490 MUST NOT offer a lease time shorter than the minimum lease time 491 specified by the client or a start time later than the maximum start 492 time specified by the client. 494 For more details about the MADCAP Server Multicast Address, see 495 section 2.10. 497 If a client sends a DISCOVER message and does not receive any OFFER 498 messages in response, the client SHOULD retransmit its DISCOVER 499 message, as described in section 2.3. 501 If a client sends a DISCOVER message and receives one or more OFFER 502 messages in response, it SHOULD select the server it wants to use (if 503 any) and send a multicast REQUEST message identifying that server 504 within [DISCOVER-DELAY] after receiving the first OFFER message. See 505 section 2.2.4 for more information about the REQUEST message. 507 The mechanism used by the client in selecting the server it wants to 508 use is implementation dependent. The value of [DISCOVER-DELAY] is 509 also implementation dependent, but the RECOMMENDED value is the 510 current retransmit timer, as specified in section 2.3. Waiting too 511 long (approaching [OFFER-HOLD]) may cause servers to drop the 512 addresses they have reserved. 514 When a MADCAP client sends a DISCOVER message, it MAY include the 515 Lease Time, Minimum Lease Time, Start Time, Maximum Start Time, 516 Number of Addresses Requested, and List of Address Ranges options, 517 describing the addresses it wants to receive. However, it need not 518 include any of these options. If one of these options is not 519 included, the server will provide the appropriate default (maximum 520 available for Lease Time, no minimum for Minimum Lease Time, as soon 521 as possible for Start Time, no maximum for Maximum Start Time, one 522 for Number of Addresses Requested, and any addresses available for 523 List of Address Ranges). The Multicast Scope option MUST be included 524 in the DISCOVER message so that the server knows what scope should be 525 used. The Current Time option MUST be included if the Start Time or 526 Maximum Start Time options are included. The Lease Identifier option 527 MUST always be included. 529 2.2.3. OFFER 531 The OFFER message is a unicast message sent by a MADCAP server in 532 response to a DISCOVER message that it can probably satisfy. 534 A MADCAP server is never required to send an OFFER message in 535 response to a DISCOVER message. For instance, it may not be able to 536 satisfy the client's request or it may have been configured to 537 respond only to certain types of DISCOVER messages or not to respond 538 to DISCOVER messages at all. 540 If a MADCAP server decides to send an OFFER message, it MUST include 541 the Lease Time and Multicast Scope options, describing the addresses 542 it is willing to provide. However, it need not include the List of 543 Address Ranges option. If the List of Address Ranges Allocated option 544 is not included, it is assumed that the server is willing to provide 545 the number of addresses that the client requested. If the Start Time 546 option is not included, it is assumed that the server is willing to 547 provide the start time requested by the client (if any). The Current 548 Time option MUST be included if the Start Time option is included. 550 If a server can process the request with a shorter lease time or 551 later start time than the client requested, it SHOULD send an OFFER 552 message with the lease time or start time that it can offer. 553 However, it MUST NOT offer a lease time shorter than the minimum 554 lease time specified by the client or a start time later than the 555 maximum start time specified by the client. 557 If the server sends an OFFER message, it SHOULD attempt to hold 558 enough addresses to complete the transaction. If it receives a 559 multicast REQUEST message with the same Lease Identifier option as 560 the DISCOVER message for which it is holding these addresses and a 561 Server Identifier option that does not match its own, it SHOULD stop 562 holding the addresses. The server SHOULD also stop holding the 563 addresses after an appropriate delay [OFFER-HOLD] if the transaction 564 is not completed. The value of this delay is implementation-specific, 565 but a value of 60 seconds is RECOMMENDED. 567 As with all messages sent by the server, the xid field MUST match the 568 xid field included in the client request to which this message is 569 responding. The Lease Identifier option MUST be included, with the 570 value matching the one included in the client request. The Server 571 Identifier option MUST be included, with the value being the server's 572 IP address. And the packet MUST NOT be retransmitted. 574 2.2.4. REQUEST 576 The REQUEST message is used by a MADCAP client that wants to allocate 577 one or more multicast addresses. It is not used for renewing an 578 existing lease. The RENEW message is used for that. 580 If a REQUEST message is completing a transaction initiated by a 581 DISCOVER message, the following procedure MUST be followed so that 582 all MADCAP servers know which server was selected. The client MUST 583 multicast a REQUEST message to the same MADCAP Server Multicast 584 Address that the DISCOVER message was sent to. The same Lease 585 Identifier used in the DISCOVER message MUST be used in the REQUEST 586 message. Also, the Server Identifier option MUST be included, using 587 the Server Identifier of the server selected. 589 If a REQUEST message is not completing a transaction initiated by a 590 DISCOVER message, the REQUEST message MUST be unicast to the MADCAP 591 server that the client wants to use. In this case, the Server 592 Identifier option MAY be included, but need not be. 594 If the selected server can process the request successfully, it 595 SHOULD unicast an ACK message to the client. Otherwise, it SHOULD 596 generate and process an error in the manner described in section 2.6. 597 If a server can process the request with a shorter lease time or 598 later start time than the client requested, it SHOULD send an ACK 599 message with the lease time or start time that it can offer. However, 600 it MUST NOT offer a lease time shorter than the minimum lease time 601 specified by the client or a start time later than the maximum start 602 time specified by the client. 604 When a MADCAP client sends a REQUEST message, it MAY include the 605 Lease Time, Minimum Lease Time, Start Time, Maximum Start Time, 606 Number of Addresses Requested, and List of Address Ranges options, 607 describing the addresses it wants to receive. However, it need not 608 include any of these options. If one of these options is not 609 included, the server will provide the appropriate default (maximum 610 available for Lease Time, no minimum for Minimum Lease Time, as soon 611 as possible for Start Time, no maximum for Maximum Start Time, one 612 for Number of Addresses Requested, and any addresses available for 613 List of Address Ranges). The Multicast Scope option MUST be included 614 in the REQUEST message so that the server knows what scope should be 615 used. The Current Time option MUST be included if the Start Time or 616 Maximum Start Time options are included. 618 If a client sends a REQUEST message and does not receive any ACK or 619 NAK messages in response, the client SHOULD resend its REQUEST 620 message, as described in section 2.3. 622 If the server responds with a NAK or fails to respond within a 623 reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the 624 client MAY try to find another server by sending a DISCOVER message 625 with another xid or sending a REQUEST message with another xid to 626 another server. The RECOMMENDED value for [NO-RESPONSE-DELAY] is 60 627 seconds. 629 2.2.5. ACK 631 The ACK message is used by a MADCAP server to respond affirmatively 632 to an INFORM, REQUEST, or RELEASE message. The server unicasts the 633 ACK message to the client from which it received the message to which 634 it is responding. 636 The set of options included with an ACK message differs, depending on 637 what sort of message it is responding to. 639 If the ACK message is responding to an INFORM message, it SHOULD 640 include any options requested by the client using the Option Request 641 List option. 643 If the ACK message is responding to a REQUEST message, it MUST 644 include Lease Time, Multicast Scope, and List of Address Ranges 645 options. It MAY include a Start Time option. If a Start Time option 646 is included, a Current Time option MUST also be included. If no Start 647 Time option is included, the lease is assumed to start immediately. 649 If the ACK message is responding to a RENEW message, it MUST include 650 Lease Time, Multicast Scope, and List of Address Ranges options. It 651 MAY include a Start Time option. If a Start Time option is included, 652 a Current Time option MUST also be included. If no Start Time option 653 is included, the lease is assumed to start immediately. 655 If the ACK message is responding to a RELEASE message, it MUST only 656 include Server Identifier and Lease Identifier options. 658 As with all messages sent by the server, the xid field MUST match the 659 xid field included in the client request to which this message is 660 responding. The Lease Identifier option MUST be included, with the 661 value matching the one included in the client request. The Server 662 Identifier option MUST be included, with the value being the server's 663 IP address. And the packet MUST NOT be retransmitted. 665 2.2.6. NAK 667 The NAK message is used by a MADCAP server to respond negatively to a 668 message. The server unicasts the NAK message to the client from which 669 it received the message to which it is responding. 671 As with all messages sent by the server, the xid field MUST match the 672 xid field included in the client request to which this message is 673 responding. The Lease Identifier option MUST be included, with the 674 value matching the one included in the client request. The Server 675 Identifier option MUST be included, with the value being the server's 676 IP address. The Error option MUST be included with an error code 677 indicating what went wrong. And the packet MUST NOT be retransmitted. 679 2.2.7. RENEW 681 The RENEW message is used by a MADCAP client that wants to renew a 682 multicast address lease, changing the lease time or start time. 684 The client unicasts the RENEW message to a MADCAP server. If the 685 server can process the request successfully, it SHOULD unicast an ACK 686 message to the client. Otherwise, it MUST generate and process an 687 error in the manner described in section 2.6. 689 The lease to be renewed is whichever one was allocated with a Lease 690 Identifier option matching the one provided in the RENEW message. 692 When a MADCAP client sends a RENEW message, it MAY include the Lease 693 Time, Minimum Lease Time, Start Time, and Maximum Start Time options, 694 describing the new lease it wants to receive. However, it need not 695 include any of these options. If one of these options is not 696 included, the server will provide the appropriate default (maximum 697 available for Lease Time, no minimum for Minimum Lease Time, as soon 698 as possible for Start Time, and no maximum for Maximum Start Time). 699 The Current Time option MUST be included if the Start Time or Maximum 700 Start Time options are included. 702 If a client sends a RENEW message and does not receive any ACK or NAK 703 messages in response, the client SHOULD resend its RENEW message, as 704 described in section 2.3. 706 If the server responds with a NAK or fails to respond within a 707 reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the 708 client MAY send a RENEW message with another xid to another server, 709 provided that the Server Mobility feature was used in the original 710 REQUEST message and that this feature is required for the subsequent 711 RENEW message sent to another server. For more information about the 712 Server Mobility feature, see section 2.13.1. The RECOMMENDED value 713 for [NO-RESPONSE-DELAY] is 60 seconds. 715 2.2.8. RELEASE 717 The RELEASE message is used by a MADCAP client that wants to 718 deallocate one or more multicast addresses before their lease 719 expires. 721 The client unicasts the RELEASE message to the MADCAP server from 722 which it allocated the addresses. If the selected server can process 723 the request successfully, it SHOULD unicast an ACK message to the 724 client. Otherwise, it MUST generate and process an error in the 725 manner described in section 2.6. 727 The lease to be released is whichever one was allocated with a Lease 728 Identifier option matching the one provided in the RELEASE message. 729 It is not possible to release only part of the addresses in a single 730 lease. 732 If a client sends a RELEASE message and does not receive any ACK or 733 NAK messages in response, the client SHOULD resend its RELEASE 734 message, as described in section 2.3. 736 If the server responds with a NAK or fails to respond within a 737 reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the 738 client MAY send a RELEASE message with another xid to another server, 739 provided that the Server Mobility feature was used in the original 740 REQUEST message and that this feature is required for the subsequent 741 RELEASE message sent to another server. For more information about 742 the Server Mobility feature, see section 2.13.1. The RECOMMENDED 743 value for [NO-RESPONSE-DELAY] is 60 seconds. 745 2.3. Retransmission 747 MADCAP clients are responsible for all message retransmission. The 748 client MUST adopt a retransmission strategy that incorporates an 749 exponential backoff algorithm to determine the delay between 750 retransmissions. The delay between retransmissions SHOULD be chosen 751 to allow sufficient time for replies from the server to be delivered 752 based on the characteristics of the internetwork between the client 753 and the server. 755 The RECOMMENDED algorithm is to use a 4 second delay before the first 756 retransmission and to double this delay for each successive 757 retransmission, with a maximum delay of 16 seconds and a maximum of 758 three retransmissions. If an initial transmission was sent at time 759 (in seconds) t and no responses were received, subsequent 760 transmissions would be at t+4, t+12, and t+28. If no response has 761 been received by t+60, the client would stop retransmitting and take 762 another course of action (such as logging an error or sending a 763 message to another address. Clients SHOULD use this algorithm unless 764 there is some good reason to use another. 766 The client MAY provide an indication of retransmission attempts to 767 the user as an indication of the progress of the process. The client 768 MAY halt retransmission at any point. 770 2.4. The Lease Identifier 772 The Lease Identifier option is included in each MADCAP message. Its 773 value is used to identify a lease and MUST be unique across all 774 leases requested by all clients in a multicast address allocation 775 domain. 777 The first octet of the Lease Identifier is the Lease Identifier type. 778 Table 3 lists the Lease Identifier types defined at this time and 779 sections 2.4.1 and 2.4.2 describe these Lease Identifier types. 781 New MADCAP Lease Identifier types may only be defined by IETF 782 Consensus, as described in section 5. 784 Lease Identifier Type Name 785 --------------------- ---- 786 0 Random Lease Identifier 787 1 Address-Specific Lease Identifier 789 Table 3: MADCAP Lease Identifier Types 791 The MADCAP server does not need to parse the Lease Identifier. It 792 SHOULD use the Lease Identifier only as an opaque identifier, which 793 must be unique for each lease. The purpose of defining different 794 Lease Identifier types is to allow MADCAP clients that already have a 795 globally unique address to avoid the possibility of Lease Identifier 796 collisions by using this address together with a client-specific 797 identifier. MADCAP clients that do not have a globally unique address 798 SHOULD use Lease Identifier type 0. 800 In addition to associating client and server messages (along with the 801 msgtype and xid fields, as described in the next section), the Lease 802 Identifier is used to control who can renew or release a lease. 803 MADCAP servers SHOULD require that the Lease Identifier used in a 804 RENEW or RELEASE message match the Lease Identifier used in the 805 initial REQUEST message. If the Lease Identifier does not match, a 806 MADCAP server MUST generate and process a Lease Identifier Not 807 Recognized error in the manner described in section 2.6. 809 To provide true security with this technique, the confidentiality of 810 the Lease Identifier must be maintained by encrypting all messages 811 that contain it. Also, it must not be easy to guess the Lease 812 Identifier. A Lease Identifier that includes a long 813 cryptographically random number may be useful here. See section 4 for 814 more information about problems caused if the Lease Identifier isn't 815 kept secret. 817 2.4.1. Random Lease Identifier 819 The first octet of a Random Lease Identifier is the Lease Identifier 820 type (0 to indicate Random Lease Identifier). After this come a 821 sequence of octets, which SHOULD represent a long random number (at 822 least 16 octets) from a decent random number generator. 824 A Random Lease Identifier does not include any indication of its 825 length. It is assumed that this may be determined by external means, 826 such as a length field preceding the Lease Identifier. 828 Lease ID 829 Type Random Number 830 +---------+-------------... 831 | 0 | 832 +---------+-------------... 834 2.4.2. Address-Specific Lease Identifier 836 The first octet of an Address-Specific Lease Identifier is the Lease 837 Identifier type (1 to indicate Address-Specific Lease Identifier). 838 After this comes a two octet IANA-defined address family number 839 (including those defined in [10]), an address from the specified 840 address family, and a client-specific identifier (such as a sequence 841 number or the current time). 843 An Address-Specific Lease Identifier does not include any indication 844 of its length. It is assumed that this may be determined by external 845 means, such as a length field preceding the Lease Identifier. 847 Lease ID Address Family Address Client-specific 848 Type Number Identifier 849 +---------+---------+---------+-----...-----+-----...-----+ 850 | 1 | addrfamily | address | cli-spec id | 851 +---------+---------+---------+-----...-----+-----...-----+ 853 2.5. Associating Client and Server Messages 855 Messages between clients and servers are associated with one another 856 using the Lease Identifier and the xid field. As described in section 857 2.1.4, the client SHOULD choose an xid so that it is unlikely that 858 the same combination of xid, msgtype, and Lease Identifier will be 859 used for two different messages within [XID-REUSE-INTERVAL] (even 860 across multiple clients which do not communicate among themselves). 861 The Lease Identifier option, msgtype, and xid field MUST be included 862 in each message sent by the client or the server. 864 The client MUST check the Lease Identifier option and xid field in 865 each incoming message to ensure that they match the Lease Identifier 866 and xid for an outstanding transaction. If not, the message MUST be 867 ignored. The server MUST check the Lease Identifier option and xid 868 field in each incoming message to establish the proper context for 869 the message. If a server cannot process a message because it is 870 invalid for its context, the server MUST generate and process an 871 Invalid Request error, as described in section 2.6. 873 A transaction can be an attempt to allocate a multicast address 874 (consisting of DISCOVER, OFFER, REQUEST, ACK, and NAK messages), an 875 attempt to renew a lease (consisting of RENEW, ACK, and NAK 876 messages), an attempt to release a previously allocated multicast 877 address (consisting of RELEASE, ACK, and NAK messages), or an attempt 878 to acquire configuration parameters (consisting of INFORM, ACK, and 879 NAK messages). 881 2.6. Processing Errors 883 If a MADCAP server encounters an error while processing a message, 884 there are two different ways to process this error. If it is clear 885 that the message is not a NAK, the server SHOULD respond with a NAK 886 containing the appropriate Error option. However, the server MAY 887 decide to completely ignore chronic offenders. If the message is a 888 NAK or it is not clear whether the message is a NAK (for instance, 889 the message is garbled or has an incorrect version number), the 890 server SHOULD ignore the message. This avoids NAK loops. 892 If a MADCAP client encounters an error while processing a message, it 893 MUST ignore the message. 895 2.7. Multicast Scopes 897 RFC 2365 [3] provides for dividing the multicast address space into a 898 number of administrative scopes. Routers should be configured so that 899 each scope corresponds to a particular partition of the network into 900 disjoint regions. Messages sent to a multicast address that falls 901 within a certain administrative scope should only be delivered to 902 hosts that have joined that multicast group *and* fall within the 903 same region as the sender. For instance, packets sent to an address 904 in the organization-local scope should only be delivered to hosts 905 that have joined that group and fall within the same organization as 906 the sender. 908 Different sets of scopes may be in effect at different places in the 909 network and at different times. Before attempting to allocate an 910 address from an administrative scope (other than global or link- 911 level scope, which are always in effect), a MADCAP client SHOULD 912 determine that the scope is in effect at its location at this time. 913 Several techniques that a MADCAP client may use to determine the set 914 of administrative scopes in effect (the scope list) are: manual 915 configuration or configuration via MADCAP (using the Multicast Scope 916 List option). 918 If a MADCAP client is unable to determine its scope list using one of 919 these techniques, it MAY temporarily assume a scope list consisting 920 of a single scope. If it is using IPv4, it SHOULD use IPv4 Local 921 Scope (239.255.0.0/16), with a maximum TTL of 16. If it is using 922 IPv6, it SHOULD use SCOP 3, with a maximum TTL of 16. Using this 923 temporary scope list, it MAY attempt to contact a MADCAP server that 924 can provide a scope list for it. 926 When a MADCAP client requests an address with a DISCOVER or REQUEST 927 message, it MUST specify the administrative scope from which the 928 address should be allocated. This scope is indicated with the 929 Multicast Scope option. Likewise, the server MUST include the 930 Multicast Scope option in all OFFER messages and all ACK messages 931 sent in response to REQUEST messages. 933 2.8. Multicast TTL 935 Another way to limit propagation of multicast messages is by using 936 TTL scoping. This technique has several disadvantages in comparison 937 to administratively scoped multicast addresses (as described in [3]), 938 but it is currently in widespread usage. 940 With TTL scoping, areas of the network are designated as scopes. 941 Routers on the edges of these areas are configured with TTL 942 thresholds so that multicast packets are not forwarded unless their 943 remaining TTL exceeds this threshold. A packet which should be 944 restricted to a given TTL scope should have an initial TTL less than 945 that scope's TTL threshold. Similar techniques may be used with IPv6, 946 using the Hop Count field instead of the TTL field. 948 MADCAP may be used in an environment where administrative scoping is 949 not in use and TTL scoping is. Under these circumstances, a MADCAP 950 server MAY return a scope list that includes scopes with TTLs less 951 than 255. The MADCAP client MAY then allocate addresses from these 952 scopes, but MUST NOT set the TTL field of any packet sent to such an 953 address to a value greater than the maximum TTL indicated in the 954 scope list. In such an environment, it is recommended that the MADCAP 955 Server Multicast Addresses associated with the IPv4 Local Scope (or 956 SCOP 3 for IPv6) be configured using TTL thresholds so that packets 957 sent to these addresses with TTL of 16 are not sent outside an 958 appropriate boundary. This will allow MADCAP clients to use their 959 default behavior for finding MADCAP servers. 961 In an environment where administrative scoping is in use, the maximum 962 TTLs in the scope list SHOULD be 255. The admin scope zone boundary 963 routers will prevent leakage of MADCAP packets beyond appropriate 964 limits. 966 2.9. Locating MADCAP Servers 968 There are several ways for a MADCAP client to locate a MADCAP server. 969 For instance, the client may be configured with an IP address. 971 The RECOMMENDED technique is for the client to send an INFORM message 972 to a MADCAP Server Multicast Address and wait for ACK responses. This 973 technique is described in more detail in the next section. 975 2.10. MADCAP Server Multicast Address 977 Each multicast scope has an associated MADCAP Server Multicast 978 Address. This address has been reserved by the IANA as the address 979 with a relative offset of -1 from the last address of a multicast 980 scope. 982 A MADCAP client looking for servers that can provide multicast 983 allocation services MAY send an INFORM message to a MADCAP Server 984 Multicast Address. Any MADCAP servers listening to this address 985 SHOULD respond with a unicast ACK message to the client if they wish 986 to offer a response. 988 The MADCAP Server Multicast Address used by a client MAY be 989 established by configuration. If a client has no such configuration, 990 it SHOULD use the MADCAP Server Multicast Address associated with 991 IPv4 Local Scope (or SCOP 3 for IPv6) with maximum TTL of 16, unless 992 otherwise configured. 994 2.11. Going Beyond the Local Scope 996 If a client receives no response to a message sent to a MADCAP Server 997 Multicast Address (after retransmission), it MAY send the message to 998 a larger scope and repeat this process as necessary. However, the 999 client MUST NOT send a MADCAP message to the MADCAP Server Multicast 1000 Address associated with the global scope. 1002 This technique allows MADCAP servers to provide services for scopes 1003 in which they do not reside. However, this is a dangerous and 1004 complicated technique and is NOT RECOMMENDED at this time. 1005 Therefore, MADCAP clients SHOULD only send multicast messages to the 1006 MADCAP Server Multicast Address corresponding to the IPv4 Local Scope 1007 (or SCOP 3, if using IPv6), unless configured otherwise. 1009 MADCAP servers that wish to provide services for scopes in which they 1010 do not reside MUST make special efforts to ensure that their services 1011 meet clients' needs for largely conflict-free allocation and accurate 1012 scope list information. In particular, coordinating with other 1013 servers that provide services for this scope may be difficult. Also, 1014 establishing which scope the client is in may be difficult. If a 1015 MADCAP server is not prepared to provide services for scopes in which 1016 it does not reside, it SHOULD ignore DISCOVER and REQUEST messages 1017 whose scope does not match or enclose the scope of the MADCAP Server 1018 Multicast Address on which the request was received. It SHOULD also 1019 ignore INFORM messages that are not received on the MADCAP Server 1020 Multicast Address for IPv4 Local Scope. 1022 2.12. Clock Skew 1024 The Current Time option is used to detect and handle clock skew 1025 between MADCAP clients and servers. This option MUST be included in 1026 any MADCAP message that includes an absolute time (such as the Start 1027 Time option). It MAY be included in any DISCOVER, OFFER, REQUEST, 1028 RENEW, or ACK message. 1030 Clock skew is a situation where two systems have clocks that are not 1031 synchronized. Many protocols (such as DHCP) ignore clock skew by 1032 using relative times. MADCAP could use a similar technique, but this 1033 leads to nasty situations due to the way multicast addresses are 1034 used. 1036 For example, assume that at 1 PM UTC a client whose clock is one hour 1037 fast requests a lease for one hour starting in one hour. If we were 1038 using relative times for MADCAP, the server, whose clock is set 1039 correctly, would reserve a multicast address for 2 to 3 PM UTC and 1040 grant the request. If the client was the only one using the lease, 1041 everything would be OK. The client would start using the lease in one 1042 hour and continue for one hour. This would coincide with the time the 1043 server had reserved (although the client would think it was 3 to 4 PM 1044 UTC). 1046 However, multicast addresses are usually used by several parties at 1047 once. The client would probably use SAP (or some other mechanism for 1048 conveying SDP) to advertise a session using the multicast address 1049 just leased. SDP uses absolute times, since it may be sent via email, 1050 web, or other store-and-forward mechanisms. So the client would 1051 advertise the session as running from 3 to 4 PM UTC. Any clients 1052 whose clocks are set correctly would use the address during this 1053 interval. Since the server only reserved the address from 2 to 3 PM 1054 UTC, this might cause the address to be used for multiple sessions 1055 simultaneously. 1057 MADCAP cannot solve all clock skew problems. That is the domain of 1058 NTP [4]. However, it does attempt to detect substantial clock skew 1059 between MADCAP clients and servers so that this clock skew does not 1060 cause massive collisions in multicast address usage later on. 1062 The Current Time option contains the sender's opinion of the current 1063 time in UTC at or about the time the message was assembled. Because 1064 of delays in transmission and processing, this value will rarely 1065 match the receiver's opinion of the current time at the time the 1066 option is processed by the receiver. However, difference greater than 1067 a minute or two probably indicate clock skew between the sender and 1068 the receiver. 1070 MADCAP servers SHOULD expect and tolerate a small amount of clock 1071 skew with their clients by ensuring that multicast addresses are 1072 allocated for an extra period of time [EXTRA-ALLOCATION-TIME] on 1073 either side of the lease given to the client. However, large amounts 1074 of clock skew require special handling. The value of [EXTRA- 1075 ALLOCATION-TIME] MUST be a configurable parameter, since local 1076 circumstances may vary. The RECOMMENDED default is one hour. 1078 However, large amounts of clock skew will cause problems later when 1079 sessions are advertised. If a MADCAP server detects clock skew 1080 greater than [CLOCK-SKEW-ALLOWANCE], it MUST generate and process an 1081 Excessive Clock Skew error, as described in section 2.6. The server 1082 MAY also log a message. The value of [CLOCK-SKEW-ALLOWANCE] MUST be a 1083 configurable parameter, since local circumstances may vary. The 1084 RECOMMENDED default is 30 minutes. 1086 2.13. Optional Features 1088 Each MADCAP client or server MAY implement one or more optional 1089 features. Optional features of MADCAP are identified with a two 1090 octet feature code. 1092 A MADCAP client MAY request, require, or indicate support for an 1093 optional feature by including a Feature List option in a message. For 1094 more information about optional features, see the description of the 1095 Feature List option. 1097 Table 4 lists the feature codes defined at this time and sections 1098 2.13.1 and 2.13.2 describe how these features work. 1100 New MADCAP feature codes may only be defined by IETF Consensus, as 1101 described in section 5. 1103 Feature Code Feature Name 1104 ------------ ------------ 1105 0 Server Mobility 1106 1 Retry After 1108 Table 4: MADCAP Feature Codes 1110 2.13.1. Server Mobility 1112 The Server Mobility feature allows an address allocated on one MADCAP 1113 server to be renewed or released on a different MADCAP server. This 1114 requires communication and coordination among MADCAP servers. The 1115 primary benefits are immunity to the failure of a single MADCAP 1116 server and perhaps greater performance through load balancing. 1118 In order to take advantage of the Server Mobility feature, a MADCAP 1119 client must ensure that the feature is implemented by both the server 1120 that is used for the original allocation and the server that is used 1121 for the renewal or release. The best way to ensure this is to include 1122 the Server Mobility feature in the required list of a Feature List 1123 option in the REQUEST message used to allocate the address (and the 1124 DISCOVER message, if one is used). When the time comes to renew or 1125 release the address, the client SHOULD send a unicast RENEW or 1126 RELEASE message to the server from which it allocated the address. 1127 However, if this server is unavailable, the client MAY send the RENEW 1128 or RELEASE message to any other server that includes the Server 1129 Mobility feature in its list of supported features. The client can 1130 find such a server by (for instance) sending an INFORM message with 1131 an Option Request List option that includes the Feature List option 1132 code. 1134 If the MADCAP client does not want to require this feature when 1135 allocating addresses, it may include the feature in the requested 1136 list of a Feature List option and see if the server includes the 1137 feature in the required list of a Feature List option in the ACK 1138 message. 1140 Even if the Server Mobility feature is used, there is no guarantee 1141 that a server will be available to perform the renewal or release or 1142 that the renewal or release will succeed. Server connectivity may 1143 have failed, for instance. 1145 2.13.2. Retry After 1147 The Retry After feature allows a MADCAP server to ask the MADCAP 1148 client to retry its request later, as may be required when allocating 1149 large numbers of addresses or allocating addresses for a long period 1150 of time. 1152 For instance, if a MADCAP client requests 1000 addresses, 1153 administrative approval may be required or allocation of more 1154 addresses from another MASC domain may be necessary. This may take 1155 several hours or several days. If the MADCAP client and server both 1156 support the Retry After feature, the MADCAP server can send back an 1157 ACK message with a Retry Time option indicating when the addresses 1158 may be ready. The client can retry its request after the Retry Time 1159 to get the addresses. 1161 If a MADCAP client includes the Retry After feature in the supported 1162 list of a Feature List option in a REQUEST message, a MADCAP server 1163 that supports the Retry After feature MAY decide to begin a lengthy 1164 allocation process. In this case, the MADCAP server will include an 1165 empty List of Address Ranges option in its ACK message, a Feature 1166 List option that includes the Retry After feature in the required 1167 list, and a Retry Time option with a time after which the client 1168 should retry the REQUEST. 1170 The client MUST NOT include the Retry After feature in the requested 1171 or required list of a Feature List option, since the decision about 1172 whether Retry After is desirable should be left to the MADCAP server. 1174 At some later time (preferably after the time indicated in the Retry 1175 Time option), the client SHOULD send a REQUEST message with all the 1176 same options as the original REQUEST message (especially the Lease 1177 Identifier option), but with a new xid value. The server MAY return 1178 a normal ACK or NAK message at this point or it MAY continue the 1179 transaction to a later time by including an empty List of Address 1180 Ranges option in its ACK message, a Feature List option that includes 1181 the Retry After feature in the required list, and a Retry Time option 1182 with a later time after which the client should retry the REQUEST. 1184 At any point after receiving the initial ACK message with the Retry 1185 Time option, the client MAY terminate the allocation process and any 1186 accompanying lease by sending to the server performing the allocation 1187 (or another server if the Server Mobility feature is also in effect) 1188 a RELEASE message with the Lease Identifier included in the original 1189 REQUEST message. 1191 The Retry After feature may also be used when renewing a lease. In 1192 this case, the description above applies except that the client sends 1193 a RENEW message instead of a REQUEST message. 1195 If a client sends a RENEW message with a Lease Identifier that 1196 matches a lease which is currently undergoing allocation with the 1197 Retry After feature in response to a REQUEST message, the server 1198 SHOULD ignore the RENEW message. Also, if a client sends a RENEW 1199 message with a Lease Identifier that matches a lease which is 1200 currently undergoing allocation with the Retry After feature in 1201 response to a RENEW message, but the options supplied with the two 1202 RENEW messages do not match, the server SHOULD ignore the second 1203 RENEW message. 1205 Note that the Retry After feature may complicate the application API. 1206 For this reason, a MADCAP client may request the Retry After feature 1207 for some messages and not for others. This should not cause problems 1208 for a robust MADCAP server. In general, servers should not expect 1209 consistent behavior from clients except as required by this 1210 specification. This also applies to clients' expectations. 1212 3. MADCAP Options 1214 As described earlier, each MADCAP message includes an options field 1215 consists of a list of tagged parameters that are called "options". 1216 All options consist of a two octet option code and a two octet option 1217 length, followed by the number of octets specified by the option 1218 length. 1220 This section defines a set of option codes for use in MADCAP 1221 messages. New options may be defined using the process defined in 1222 section 5. The options are listed in numerical order. 1224 Table 5 summarizes which options are allowed with each message type. 1226 Option INFORM ACK (in response to INFORM) 1227 ------ ------ --------------------------- 1228 Lease Time MUST NOT MUST NOT 1229 Server Identifier MUST NOT MUST 1230 Lease Identifier MUST MUST 1231 Multicast Scope MUST NOT MUST NOT 1232 Option Request List MUST MUST NOT 1233 Start Time MUST NOT MUST NOT 1234 Number of Addresses 1235 Requested MUST NOT MUST NOT 1236 Requested Language MAY MUST NOT 1237 Multicast Scope List MUST NOT MAY 1238 List of Address Ranges MUST NOT MUST NOT 1239 Current Time MUST NOT MAY 1240 Feature List MAY MAY 1241 Retry Time MUST NOT MUST NOT 1242 Minimum Lease Time MUST NOT MUST NOT 1243 Maximum Start Time MUST NOT MUST NOT 1244 Error MUST NOT MUST NOT 1245 Option DISCOVER OFFER 1246 ------ -------- ----- 1247 Lease Time MAY MUST 1248 Server Identifier MUST NOT MUST 1249 Lease Identifier MUST MUST 1250 Multicast Scope MUST MUST 1251 Option Request List MUST NOT MUST NOT 1252 Start Time MAY MAY 1253 Number of Addresses 1254 Requested MAY MUST NOT 1255 Requested Language MUST NOT MUST NOT 1256 Multicast Scope List MUST NOT MUST NOT 1257 List of Address Ranges MAY MAY 1258 Current Time MAY MAY 1259 Feature List MAY MAY 1260 Retry Time MUST NOT MUST NOT 1261 Minimum Lease Time MAY MUST NOT 1262 Maximum Start Time MAY MUST NOT 1263 Error MUST NOT MUST NOT 1265 Option REQUEST ACK (in response to REQUEST) 1266 ------ ------- ---------------------------- 1267 Lease Time MAY MUST 1268 Server Identifier MUST (if MUST 1269 multicast) 1270 Lease Identifier MUST MUST 1271 Multicast Scope MUST MUST 1272 Option Request List MUST NOT MUST NOT 1273 Start Time MAY MAY 1274 Number of Addresses 1275 Requested MAY MUST NOT 1276 Requested Language MUST NOT MUST NOT 1277 Multicast Scope List MUST NOT MUST NOT 1278 List of Address Ranges MAY MUST 1279 Current Time MAY MAY 1280 Feature List MAY MAY 1281 Retry Time MUST NOT MAY 1282 Minimum Lease Time MAY MUST NOT 1283 Maximum Start Time MAY MUST NOT 1284 Error MUST NOT MUST NOT 1286 Option RENEW ACK (in response to RENEW) 1287 ------ ----- -------------------------- 1288 Lease Time MAY MUST 1289 Server Identifier MUST NOT MUST 1290 Lease Identifier MUST MUST 1291 Multicast Scope MUST NOT MUST 1292 Option Request List MUST NOT MUST NOT 1293 Start Time MAY MAY 1294 Number of Addresses 1295 Requested MUST NOT MUST NOT 1296 Requested Language MUST NOT MUST NOT 1297 Multicast Scope List MUST NOT MUST NOT 1298 List of Address Ranges MUST NOT MUST 1299 Current Time MAY MAY 1300 Feature List MAY MAY 1301 Retry Time MUST NOT MAY 1302 Minimum Lease Time MAY MUST NOT 1303 Maximum Start Time MAY MUST NOT 1304 Error MUST NOT MUST NOT 1306 Option RELEASE ACK (in response to RELEASE) 1307 ------ ------- ---------------------------- 1308 Lease Time MUST NOT MUST NOT 1309 Server Identifier MUST NOT MUST 1310 Lease Identifier MUST MUST 1311 Multicast Scope MUST NOT MUST NOT 1312 Option Request List MUST NOT MUST NOT 1313 Start Time MUST NOT MUST NOT 1314 Number of Addresses 1315 Requested MUST NOT MUST NOT 1316 Requested Language MUST NOT MUST NOT 1317 Multicast Scope List MUST NOT MUST NOT 1318 List of Address Ranges MUST NOT MUST NOT 1319 Current Time MUST NOT MUST NOT 1320 Feature List MAY MAY 1321 Retry Time MUST NOT MUST NOT 1322 Minimum Lease Time MUST NOT MUST NOT 1323 Maximum Start Time MUST NOT MUST NOT 1324 Error MUST NOT MUST NOT 1326 Option NAK 1327 ------ --- 1328 Lease Time MUST NOT 1329 Server Identifier MUST 1330 Lease Identifier MUST 1331 Multicast Scope MUST NOT 1332 Option Request List MUST NOT 1333 Start Time MUST NOT 1334 Number of Addresses 1335 Requested MUST NOT 1336 Requested Language MUST NOT 1337 Multicast Scope List MUST NOT 1338 List of Address Ranges MUST NOT 1339 Current Time MUST NOT 1340 Feature List MAY 1341 Retry Time MUST NOT 1342 Minimum Lease Time MUST NOT 1343 Maximum Start Time MUST NOT 1344 Error MUST 1346 Table 5: Options allowed in MADCAP messages 1348 3.1. End 1350 The End option marks the end of valid information in the options 1351 field. This option MUST be included at the end of the options field 1352 in each MADCAP message. 1354 The code for this option is 0, and its length is 0. 1356 Code Len 1357 +-----+-----+-----+-----+ 1358 | 0 | 0 | 1359 +-----+-----+-----+-----+ 1361 3.2. Lease Time 1363 This option is used in a client request (DISCOVER, REQUEST, or RENEW) 1364 to allow the client to request a lease time for the multicast 1365 address. In a server reply (OFFER or ACK), a MADCAP server uses this 1366 option to specify the lease time it is willing to offer. 1368 The time is in units of seconds, and is specified as a 32-bit 1369 unsigned integer. 1371 The code for this option is 1, and its length is 4. 1373 Code Len Lease Time 1374 +-----+-----+-----+-----+-----+-----+-----+-----+ 1375 | 1 | 4 | t1 | t2 | t3 | t4 | 1376 +-----+-----+-----+-----+-----+-----+-----+-----+ 1378 3.3. Server Identifier 1380 This option contains the IP address of a MADCAP server. A two octet 1381 address family number (as defined by IANA, including those defined in 1382 [10]) is stored first, followed by the address. The address family 1383 for this address is not determined by the addrfamily field in the 1384 fixed header so that addresses from one family may be allocated while 1385 communicating with a server via addresses of another family. 1387 All messages sent by a MADCAP server MUST include a Server Identifier 1388 option with the IP address of the server sending the message. 1390 MADCAP clients MUST include a Server Identifier option in multicast 1391 REQUEST messages in order to indicate which OFFER message has been 1392 accepted. 1394 The code for this option is 2, and its minimum length is 3. 1396 Code Len Address Family Address 1397 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 1398 | 2 | n | family | a1 | ... | 1399 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 1401 3.4. Lease Identifier 1403 This option is used by MADCAP clients to specify a unique lease 1404 identifier. For more information about this option and how it is 1405 used, see section 2.4. 1407 The code for this option is 3, and its minimum length is 1. 1409 Code Len Lease Identifier 1410 +-----+-----+-----+-----+-----+-----+--- 1411 | 3 | n | i1 | i2 | ... 1412 +-----+-----+-----+-----+-----+-----+--- 1414 3.5. Multicast Scope 1416 The multicast scope option is used by the client to indicate the 1417 requested multicast scope in a DISCOVER or REQUEST message. It is 1418 also used by the MADCAP server to indicate the scope of an assigned 1419 address. 1421 The client may obtain the scope list through the Multicast Scope List 1422 option or using some other means. The Scope ID is the first multicast 1423 address in the scope. The address family of the Scope ID is 1424 determined by the addrfamily field. 1426 The code for this option is 4, and its minimum length is 1. 1428 Code Len Scope ID 1429 +-----+-----+-----+-----+-----+----- 1430 | 4 | n | i1 | ... 1431 +-----+-----+-----+-----+-----+----- 1433 3.6. Option Request List 1435 This option is used by a MADCAP client in an INFORM message to 1436 request that certain options be included in the server's ACK 1437 response. The server SHOULD try to include the specified options in 1438 its response, but is not required to do so. 1440 The format of this option is a list of option codes. 1442 The code for this option is 5 and the minimum length is 2. 1444 Code Len Requested Options 1445 +-----+-----+-----+-----+-----+-----+---... 1446 | 5 | n | Option1 | 1447 +-----+-----+-----+-----+-----+-----+---... 1449 3.7. Start Time 1451 The Start Time option specifies the starting time for a multicast 1452 address lease. 1454 A client may include this option in a DISCOVER, RENEW, or REQUEST 1455 message to request a multicast address for use at a future time. A 1456 server may include this option in an OFFER message or in an ACK in 1457 response to REQUEST or RENEW message to indicate that a lease has 1458 been granted which starts at a future time. 1460 If the Start Time option is present, the IP Address Lease Time option 1461 specifies the duration of the lease beginning at the Start Time 1462 option value. 1464 If the Start Time option is present, the Current Time option MUST 1465 also be present, as described in section 2.12. 1467 The time value is an unsigned 32 bit integer in network byte order 1468 giving the number of seconds since 00:00 UTC, 1st January 1970. This 1469 can be converted to an NTP timestamp by adding decimal 2208988800. 1470 This time format will not wrap until the year 2106. 1472 The code for this option is 6 and the length is 4. 1474 Code Len Time 1475 +-----+-----+-----+-----+-----+-----+-----+-----+ 1476 | 6 | 4 | t1 | t2 | t3 | t4 | 1477 +-----+-----+-----+-----+-----+-----+-----+-----+ 1479 3.8. Number of Addresses Requested 1481 This option specifies the minimum and desired number of addresses 1482 requested by the client. It is only used in DISCOVER and REQUEST 1483 messages and is only sent by the client. 1485 The minimum and desired number of addresses requested are unsigned 16 1486 bit integers in network byte order. The minimum MUST be less than or 1487 equal to the desired number. If a message is received where this is 1488 not the case, the MADCAP server MUST generate and process an Invalid 1489 Request error in the manner described in section 2.6. 1491 The client MAY obtain more than one address either by repeating the 1492 protocol for every address or by requesting several addresses at the 1493 same time via this option. When the client is requesting only one 1494 address, this option SHOULD NOT be included. A MADCAP server 1495 receiving a DISCOVER or REQUEST packet including this option MUST 1496 include between the minimum and desired number of addresses in any 1497 OFFER or ACK response. 1499 The code for this option is 7 and the length is 4. 1501 Code Len Minimum Desired 1502 +-----+-----+-----+-----+-----+-----+-----+-----+ 1503 | 7 | 4 | min | desired | 1504 +-----+-----+-----+-----+-----+-----+-----+-----+ 1506 3.9. Requested Language 1508 This option specifies the language in which the MADCAP client would 1509 like strings such as zone names to be returned. It is only included 1510 in an INFORM message sent by the client. It is an RFC 1766 [6] 1511 language tag. The proper way to handle this tag with respect to zone 1512 names is discussed further in the definition of the Multicast Scope 1513 List option. 1515 The code for this option is 8 and the minimum length is 0. 1517 Code Len Language Tag 1518 +-----+-----+-----+-----+-----+-...-+-----+ 1519 | 8 | n | L1 | | Ln | 1520 +-----+-----+-----+-----+-----+-...-+-----+ 1522 3.10. Multicast Scope List 1524 This option is sent by the server in an ACK message in response to an 1525 INFORM message sent by the client. 1527 If the client did not include a Requested Language option in its 1528 INFORM message, the MADCAP server SHOULD return all zone names for 1529 each zone. If the client included a Requested Language option in its 1530 INFORM message, the MADCAP server MUST return no more than one zone 1531 name for each zone. For each zone, the MADCAP server SHOULD first 1532 look for a zone name that matches the requested language tag (using a 1533 case-insensitive ASCII comparison). If any names match, one of them 1534 should be returned. Otherwise, the MADCAP server SHOULD choose 1535 another zone name to return (if any are defined). It SHOULD give 1536 preference to zone names that are marked to be used if no name is 1537 available in a desired language. 1539 The code for this option is 9 and the minimum length is 0. 1541 The format of the multicast scope list option is: 1543 Code Len Count Scope List 1544 +-----+-----+-----+-----+-----+-----+-...-+-----+ 1545 | 9 | p | m | L1 | | Lm | 1546 +-----+-----+-----+-----+-----+-----+-...-+-----+ 1548 The scope list is a list of m tuples, where each tuple is of the 1549 form: 1551 Scope ID Last Address TTL Name Encoded Name List 1552 Count 1553 +---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+ 1554 | ... ID ... | ... Last ... | T | n | EN1 | | ENn | 1555 +---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+ 1557 where Scope ID is the first multicast address in the scope, Last 1558 Address is the last multicast address in the scope, TTL is the 1559 multicast TTL value for the multicast addresses of the scope, and 1560 Name Count is the number of encoded names for this zone (which may be 1561 zero). The address family of the Scope ID and Last Address is 1562 determined by the addrfamily field. Note that a particular MADCAP 1563 server may be allocating addresses out of some subset of the scope. 1564 For instance, the addresses in the scope may be divided among several 1565 servers in some way. 1567 Each encoded name is of the form 1569 Name Lang Language Tag Name Name 1570 Flags Length Length 1571 +-----+-----+-----+-...-+-----+-----+-----+-...-+-----+ 1572 | F | q | L1 | | Lq | r | N1 | | Nr | 1573 +-----+-----+-----+-...-+-----+-----+-----+-...-+-----+ 1575 where Name Flags is a flags field with flags defined below, Lang 1576 Length is the length of the Language Tag in octets (which MUST NOT be 1577 zero), Language Tag is a language tag indicating the language of the 1578 zone name (as described in [6]), Name Length is the length of the 1579 Name in octets (which MUST NOT be zero), and Name is a UTF-8 [5] 1580 string indicating the name given to the scope zone. 1582 The high bit of the Name Flags field is set if the following name 1583 should be used if no name is available in a desired language. 1584 Otherwise, this bit is cleared. All remaining bits in the octet 1585 SHOULD be set to zero and MUST be ignored. 1587 The Scope IDs of entries in the list MUST be unique and the scopes 1588 SHOULD be listed from smallest (topologically speaking) to largest. 1589 This makes it easier to display a consistent user interface, with 1590 scopes usually keeping the same order. However, scopes may not be 1591 strictly nested. In this circumstance, there is no strict ordering 1592 from smallest to largest and the server must use another technique 1593 for ordering the scope list. 1595 Example: 1597 There are two scopes supported by the multicast address allocation 1598 server: Inside abcd.com with addresses 239.192.0.0-239.195.255.255, 1599 and world with addresses 224.0.1.0-238.255.255.255. Then this option 1600 will be given as: 1602 Code Len Count 1603 +-----+-----+-----+-----+-----+... 1604 | 9 | 51 | 2 | 1605 +-----+-----+-----+-----+-----+... 1607 Scope ID Last Address TTL Name Name Lang Language 1608 Count Flags Length Tag 1609 +---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+... 1610 |239|192| 0 | 0 |239|195|255|255|10 | 1 | 128 | 2 | en | 1611 +---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+... 1613 Name 1614 Length Name 1615 +------+--+--+-...-+--+--+... 1616 | 15 | Inside abcd.com | 1617 +------+--+--+-...-+--+--+... 1619 Scope ID Last Address TTL Name Name Lang Language 1620 Count Flags Length Tag 1621 +---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+... 1622 |224| 0 | 1 | 0 |238|255|255|255|16 | 1 | 128 | 2 | en | 1623 +---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+... 1625 Name 1626 Length Name 1627 +------+--...--+ 1628 | 5 | world | 1629 +------+--...--+ 1631 3.11. List of Address Ranges 1633 This option is used by the server to provide the list of all the 1634 address ranges allocated to the client. 1636 This option is also used by the client when requesting a lease for a 1637 specific set of addresses. 1639 The address family of the addresses is determined by the addrfamily 1640 field. 1642 The code for this option is 10 and the minimum length is 0. 1644 Code Len Address Range List 1645 +-----+-----+-----+-----+-----+-----+-...-+-----+ 1646 | 10 | n | L1 | L2 | | Ln | 1647 +-----+-----+-----+-----+-----+-----+-...-+-----+ 1649 where the Address Range List is of the following format. 1651 StartAddress1 BlockSize1 StartAddress2 BlockSize2 ... 1652 +---+---+---+---+---+---+---+---+---+---+---+---+--...--+ 1653 | ... S1 ... |B11|B12| ... S2 ... |B21|B22| | 1654 +---+---+---+---+---+---+---+---+---+---+---+---+--...--+ 1656 3.12. Current Time 1658 This option is used to express what the sender thinks the current 1659 time is. This is useful for detecting clock skew. This option MUST be 1660 included if the Start Time or Maximum Start Time options are used, as 1661 described in section 2.12. 1663 The time value is an unsigned 32 bit integer in network byte order 1664 giving the number of seconds since 00:00 UTC, 1st January 1970. This 1665 can be converted to an NTP [4] timestamp by adding decimal 1666 2208988800. This time format will not wrap until the year 2106. 1668 The code for this option is 11 and the length is 4. 1670 Code Len Time 1671 +-----+-----+-----+-----+-----+-----+-----+-----+ 1672 | 11 | 4 | t1 | t2 | t3 | t4 | 1673 +-----+-----+-----+-----+-----+-----+-----+-----+ 1675 3.13. Feature List 1677 This option lists optional MADCAP features supported, requested, or 1678 required, by the sender. This option MAY be included in any message 1679 sent by a MADCAP server or client. 1681 Optional features of MADCAP are identified with a two octet feature 1682 code. New MADCAP feature codes may only be defined by IETF 1683 Consensus, as described in section 5. 1685 The Feature List option consists of three separate lists: supported 1686 features, requested features, and required features. Each list 1687 consists of an unordered list of feature codes. The supported list is 1688 used by MADCAP clients or servers to indicate the features that the 1689 sender supports. The requested and required lists are used by MADCAP 1690 clients to indicate which features are requested of or required from 1691 a MADCAP server. The required list is used by MADCAP servers to 1692 indicate which features were implemented by the MADCAP server in 1693 processing this message. Messages sent by MADCAP servers MUST NOT 1694 include any feature codes in the requested list. 1696 If a MADCAP client includes the Feature List option in a message, it 1697 MAY include features in any of the lists: supported, requested, and 1698 required. If a MADCAP server receives a message containing the 1699 Feature List option and it does not support all of the features in 1700 the required list, it MUST generate and process a Required Feature 1701 Not Supported error in the manner described in section 2.6. If the 1702 server supports all of the features in the required list, it MUST 1703 implement them as appropriate for this message. It SHOULD try to 1704 implement the features in the requested list and it MAY implement any 1705 of the features in the supported list. If an optional feature (such 1706 as Retry After) is not included in any part of the Feature List 1707 option included in the client's message (or if the client does not 1708 include a Feature List option in its message), the server MUST NOT 1709 use that feature in its response. 1711 If a MADCAP server does respond to a client's message that includes a 1712 Feature List option, the server MUST include a Feature List option 1713 with a supported features list that lists the features that it 1714 supports, a required features list that lists the features that it 1715 implemented in responding to this message (which must be included in 1716 the supported features list of the client's Feature List option), and 1717 an empty requested features list. 1719 The code for this option is 12 and the minimum length is 6. 1721 Code Len Supported Requested Required 1722 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 1723 | 12 | n | FL1 | FL2 | FL3 | 1724 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 1726 where each of the Feature Lists is of the following format: 1728 Feature Feature Feature 1729 Count Code 1 Code m 1730 +-----+-----+-----+-----+-...-+-----+-----+ 1731 | m | FC1 | | FCm | 1732 +-----+-----+-----+-----+-...-+-----+-----+ 1734 3.14. Retry Time 1736 The Retry Time option specifies the time at which a client should 1737 retry a REQUEST or RENEW message when using the Retry After feature. 1739 This option should only be sent by a MADCAP server in an ACK when 1740 responding to a REQUEST or RENEW message that includes the Retry 1741 After feature in the supported, requested, or required list. For more 1742 discussion of Retry After, see section 2.13.2. 1744 If the Retry Time option is present, the Current Time option MUST 1745 also be present. 1747 The time value is an unsigned 32 bit integer in network byte order 1748 giving the number of seconds since 00:00 UTC, 1st January 1970. This 1749 can be converted to an NTP timestamp by adding decimal 2208988800. 1750 This time format will not wrap until the year 2106. 1752 The code for this option is 13 and the length is 4. 1754 Code Len Time 1755 +-----+-----+-----+-----+-----+-----+-----+-----+ 1756 | 13 | 4 | t1 | t2 | t3 | t4 | 1757 +-----+-----+-----+-----+-----+-----+-----+-----+ 1759 3.15. Minimum Lease Time 1761 This option is used in a client request (DISCOVER, REQUEST, or RENEW) 1762 to allow the client to specify a minimum lease time for the multicast 1763 address. If a server cannot meet this minimum lease time, it MUST 1764 generate and process a Valid Request Could Not Be Completed error in 1765 the manner described in section 2.6. 1767 The time is in units of seconds, and is specified as a 32-bit 1768 unsigned integer. 1770 The code for this option is 14, and its length is 4. 1772 Code Len Lease Time 1773 +-----+-----+-----+-----+-----+-----+-----+-----+ 1774 | 14 | 4 | t1 | t2 | t3 | t4 | 1775 +-----+-----+-----+-----+-----+-----+-----+-----+ 1777 3.16. Maximum Start Time 1779 The Maximum Start Time option specifies the latest starting time that 1780 the client is willing to accept for a multicast address lease. 1782 A client may include this option in a DISCOVER, RENEW, or REQUEST 1783 message to specify that it does not want to receive a lease with a 1784 starting time later than the specified value. If a server cannot meet 1785 this maximum start time, it MUST generate and process a Valid Request 1786 Could Not Be Completed error in the manner described in section 2.6. 1788 If the Maximum Start Time option is present, the Current Time option 1789 MUST also be present, as described in section 2.12. 1791 The time value is an unsigned 32 bit integer in network byte order 1792 giving the number of seconds since 00:00 UTC, 1st January 1970. This 1793 can be converted to an NTP timestamp by adding decimal 2208988800. 1794 This time format will not wrap until the year 2106. 1796 The code for this option is 15 and the length is 4. 1798 Code Len Time 1799 +-----+-----+-----+-----+-----+-----+-----+-----+ 1800 | 15 | 4 | t1 | t2 | t3 | t4 | 1801 +-----+-----+-----+-----+-----+-----+-----+-----+ 1803 3.17. Error 1805 A MADCAP server includes this option in a NAK message to indicate why 1806 the request failed. A MADCAP server MUST include an Error option in 1807 each NAK message. 1809 The first two octets of an Error option contain a MADCAP error code. 1810 Several MADCAP error codes are defined later in this section. New 1811 MADCAP error codes may only be defined by IETF Consensus, as 1812 described in section 5. 1814 Any remaining octets in the Error option contain extra data about the 1815 error. The format of this data depends on the error code. The 1816 definition of a MADCAP error code must include a definition of the 1817 extra data to be included with that error code. 1819 A client that receives a NAK message containing an Error option MAY 1820 log or display a message indicating the error code and extra data 1821 received. The client MUST NOT retransmit a message once a NAK 1822 response to that message has been received. The client MAY adjust the 1823 message to correct the error and send the corrected message or send a 1824 message to a different server. 1826 The code for this option is 16, and the minimum length is 2. 1828 Code Len Error Code Extra Data 1829 +-----+-----+-----+-----+-----+-----+-----+-----+ ... 1830 | 16 | n | ecode | d1 d2 1831 +-----+-----+-----+-----+-----+-----+-----+-----+ ... 1833 3.17.1. Valid Request Could Not Be Completed 1835 MADCAP error code 0 indicates that the request was valid, but could 1836 not be completed with the available addresses and the current 1837 configuration. The extra data is a two octet option code indicating 1838 which option caused the problem. A value of 0xFFFF indicates that the 1839 problem was not with a specific option. 1841 3.17.2. Invalid Request 1843 MADCAP error code 1 indicates that the request was malformed or 1844 invalid in some other manner. The extra data is a two octet option 1845 code indicating which option caused the problem. A value of 0xFFFF 1846 indicates that the problem was not with a specific option. 1848 3.17.3. Excessive Clock Skew 1850 MADCAP error code 2 indicates excessive clock skew (see section 1851 2.12). The extra data consists of a four octet time value 1852 representing the server's idea of the current time, an unsigned 32 1853 bit integer in network byte order giving the number of seconds since 1854 00:00 UTC, 1st January 1970. This can be converted to an NTP 1855 timestamp by adding decimal 2208988800. This time format will not 1856 wrap until the year 2106. 1858 3.17.4. Lease Identifier Not Recognized 1860 MADCAP error code 3 indicates that the Lease Identifier was not 1861 recognized (usually in response to a RENEW or RELEASE message). There 1862 is no extra data. 1864 3.17.2. Required Feature Not Supported 1866 MADCAP error code 4 indicates that at least one feature included in 1867 the required list of the Feature List option is not supported. The 1868 extra data contains a list of the feature codes in the required list 1869 that are not supported. 1871 3.17.5. Experimental Use 1873 MADCAP error codes 1024-2047 are reserved for experimental use. The 1874 format of the extra data included with these error codes is not 1875 defined. 1877 4. Security Considerations 1879 MADCAP has relatively basic security requirements. At present there 1880 is no way of enforcing authorized use of multicast addresses in the 1881 multicast routing/management protocols. Therefore, it is not 1882 possible to identify unauthorized use of multicast address by an 1883 adversary. Moreover, a multicast address allocated to a user/system 1884 can be used by other systems without violating terms of the multicast 1885 address allocation. For example, a system may reserve an address to 1886 be used for a work group session where each and every member of the 1887 work group is allowed to transmit packets using the allocated group 1888 address. In other words, the multicast address allocation protocol 1889 does not dictate how the address should be used, it only dictates the 1890 time period for which it can be used and who gets to release it or 1891 renew it. When an address is allocated to a system/user, it basically 1892 means that no other user/system (most likely) will be allocated that 1893 address for the time period, without any restrictions on its use. 1895 To protect against rogue MADCAP servers (mis-configured servers and 1896 intentional), clients in certain situations would like to 1897 authenticate the server. Similarly, for auditing or book-keeping 1898 purposes, the server may want to authenticate clients. Moreover, in 1899 some cases, the server may have certain policies in place to restrict 1900 the number of addresses that are allocated to a system or a user. 1901 This feature is of much value when a well behaved but naive user or 1902 client requests a large number of addresses, and therefore, 1903 inadvertently impacts other users or systems. Therefore, an 1904 administrator may want to exert a limited amount of control based on 1905 the client identification. The client identification could be based 1906 on the system or user identity. In most practical situations, system 1907 identification will suffice, however, particularly in case of 1908 multi-user systems, at times, user identification will play an 1909 important role. Therefore, authentication capabilities based on user 1910 identification may be desirable. As usual, data integrity is a strong 1911 requirement and if not protected, can lead to many problems including 1912 denial of service attacks. 1914 In the case of MADCAP, confidentiality is not a strong requirement. 1915 In most of the cases, at least when a multicast address is in use, an 1916 adversary will be able to determine information that was contained in 1917 the MADCAP messages. In some cases, the users/systems may want to 1918 protect information in the MADCAP messages so that an adversary is 1919 not able to determine relevant information in advance and thus, plan 1920 an attack in advance. For example, if an adversary knows in advance 1921 (based on MADCAP messages) that a particular user has requested large 1922 number of address for certain time period and scope, he may be able 1923 to guess the purpose behind such request and target an attack. If 1924 MADCAP servers are configured to allow renewal or release purely on 1925 the basis of knowledge of the Lease Identifier option (without 1926 consideration of authentication), preserving the confidentiality of 1927 MADCAP messages becomes more important. Also, there may be features 1928 added to the protocol in the future that may have stronger 1929 confidentiality requirements. 1931 The IPSEC protocol [8] meets client/server identification and 1932 integrity protection requirements stated above, requires no 1933 modification to the MADCAP protocol, and leverages extensive work in 1934 IETF and industry. Therefore, when security is a strong requirement, 1935 IPSEC SHOULD be used for protecting all the unicast messages of 1936 MADCAP protocol. When IPSEC based security is in use, all the 1937 multicast packets except INFORM MUST be dropped by the MADCAP server. 1938 The prevalent implementations of IPSEC support client identification 1939 in form of system identification and do not support user 1940 identification. However, when desired, IPSEC with appropriate API's 1941 may be required to support user identification. 1943 5. IANA Considerations 1945 This document defines several number spaces (MADCAP options, MADCAP 1946 message types, MADCAP Lease Identifier types, MADCAP features, and 1947 MADCAP error codes). For all of these number spaces, certain values 1948 are defined in this specification. New values may only be defined by 1949 IETF Consensus, as described in [7]. Basically, this means that they 1950 are defined by RFCs approved by the IESG. 1952 6. Acknowledgments 1954 The authors would like to thank Rajeev Byrisetty, Steve Deering, 1955 Peter Ford, Mark Handley, Van Jacobson, David Oran, Thomas Pfenning, 1956 Dave Thaler, Ramesh Vyaghrapuri and the participants of the IETF for 1957 their assistance with this protocol. 1959 Much of this document is based on [1] and [2]. The authors of this 1960 document would like to express their gratitude to the authors of 1961 these previous works. Any errors in this document are solely the 1962 fault of the authors of this document. 1964 7. References 1966 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 1967 March 1997. 1969 [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor 1970 Extensions", RFC 2132, March 1997. 1972 [3] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, 1973 July 1998. 1975 [4] Mills, D., "Network Time Protocol (Version 3) Specification, 1976 Implementation and Analysis", RFC 1305, March 1992. 1978 [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1979 2279, January 1998. 1981 [6] Alvestrand, H., "Tags for the Identification of Languages", RFC 1982 1766, March 1995. 1984 [7] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 1985 Considerations Section in RFCs", RFC 2434, October 1998. 1987 [8] Atkinson, R. and S. Kent, "Security Architecture for the Internet 1988 Protocol", RFC 2401, November 1998. 1990 [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1991 Levels", RFC 2119, March 1997. 1993 [10] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. 1995 [11] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1112, October 1994. 1997 [12] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 2460, October 1994. 1999 [13] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 2373, October 1994. 2001 8. Authors' Addresses 2003 Stephen R. Hanna 2004 Sun Microsystems, Inc. 2005 One Network Drive 2006 Burlington, MA 01803 2007 Phone: +1.781.442.0166 2008 Email: steve.hanna@sun.com 2010 Baiju V. Patel 2011 Intel Corp. 2012 Mail Stop: AG2-201 2013 5200 NE Elam Young Parkway 2014 Hillsboro, OR 97124 2016 Phone: 503 696 8192 2017 EMail: baiju.v.patel@intel.com 2019 Munil Shah 2020 Microsoft Corporation 2021 One Microsoft Way 2022 Redmond, WA 98052 2024 Phone: 425 703 3924 2025 Email: munils@microsoft.com 2027 APPENDIX A: Examples 2029 This appendix includes several examples of typical MADCAP protocol 2030 exchanges. 2032 1. Multicast Scope List Discovery 2034 In this example, a MADCAP client wants to determine the scope list in 2035 effect. The client is using IPv4, so it starts by multicasting an 2036 INFORM packet to the MADCAP Server Multicast Address corresponding to 2037 IPv4 Local Scope. This packet includes the Lease Identifier option, 2038 an Option Request List including the Multicast Scope List option 2039 code, and a Requested Language option containing the string "en", 2040 since the client is configured to prefer the English language. 2042 Two MADCAP servers respond by sending ACK messages. These ACK 2043 messages include the Lease Identifier option and xid supplied by the 2044 client, the server's Server Identifier, and the Multicast Scope List 2045 with one name per scope (the one that most closely matches the 2046 language tag "en"). 2048 The following figure illustrates this exchange. 2050 Server Client Server 2051 v v v 2052 | | | 2053 | | | 2054 | _____________/|\_____________ | 2055 |/ INFORM | INFORM \| 2056 | | | 2057 | | | 2058 |\ | ____________/| 2059 | \_________ | / ACK | 2060 | ACK \ |/ | 2061 | \ | | 2062 | | | 2063 v v v 2065 Figure 2: Timeline diagram of messages exchanged 2066 in Multicast Scope List Discovery example 2068 2. Multicast Discovery and Address Allocation 2070 In this example, the MADCAP client wants to allocate a multicast 2071 address from the global scope for use during the next two hours. 2073 The client begins by multicasting a DISCOVER packet to the MADCAP 2074 Server Multicast Address associated with IPv4 Local Scope. This 2075 packet includes the Lease Time, Lease Identifier, and Multicast Scope 2076 options. 2078 Any servers that receive the DISCOVER packet and can satisfy this 2079 request temporarily reserve an address for the client and unicast an 2080 OFFER packet to the client. These packets contain the Lease Time, 2081 Server Identifier, Lease Identifier, and Multicast Scope options. 2083 After an appropriate delay, the client multicasts a REQUEST packet to 2084 the MADCAP Server Multicast Address. This packet contains all of the 2085 options included in the DISCOVER packet, but also includes the Server 2086 Identifier option, indicating which server it has selected for the 2087 request. 2089 The server whose Server Identifier matches the one specified by the 2090 client responds with an ACK packet containing the options included in 2091 the OFFER packet, as well as a List of Address Ranges option listing 2092 the address allocated. All the other servers that had sent OFFER 2093 packets stop reserving an address for the client and forget about the 2094 whole exchange. 2096 The client now has a two hour "lease" on the multicast address. 2098 If the client had not received an ACK from the server, it would have 2099 retransmitted its REQUEST packet for a while. If it still received no 2100 response, it would start over with a new DISCOVER message. 2102 The following figure illustrates this exchange. 2104 Server Client Server 2105 (not selected) (selected) 2106 v v v 2107 | | | 2108 |Begin multicast address request| 2109 | | | 2110 | _____________/|\_____________ | 2111 |/ DISCOVER | DISCOVER \| 2112 | | | 2113 Reserves | Reserves 2114 Address | Address 2115 | | | 2116 |\ | ____________/| 2117 | \_________ | / OFFER | 2118 | OFFER \ |/ | 2119 | \ | | 2120 | Collects replies | 2121 | \| | 2122 | Selects Server | 2123 | | | 2124 | _____________/|\_____________ | 2125 |/ REQUEST | REQUEST \| 2126 | | | 2127 | | Commits address 2128 | | | 2129 | | _____________/| 2130 | |/ ACK | 2131 | | | 2132 | assignment complete | 2133 | | | 2134 v v v 2136 Figure 3: Timeline diagram of messages exchanged 2137 in Multicast Address Allocation example 2139 3. Lease Extension 2141 This is a continuation of the previous example. The client has 2142 already allocated a multicast address from the global scope for use 2143 during the next two hours. Half way through this two hour period, it 2144 decides that it wants to extend its lease for another hour. 2146 The client unicasts a RENEW packet to the server from which it 2147 allocated the address. This packet includes the Lease Time and Lease 2148 Identifier options. The Lease Identifier matches the one used for the 2149 original allocation. The time included in the Lease Time is two 2150 hours, since the client wants the lease to expire two hours from the 2151 current time. 2153 The server responds with an ACK packet indicating that the lease 2154 extension has been granted. This packet includes the Lease Time, 2155 Server Identifier, Lease Identifier, Multicast Scope, and List of 2156 Address Ranges options. 2158 If the server did not want to grant the requested lease extension, it 2159 would have responded with a NAK packet with the Lease Identifier 2160 option. 2162 The following figure illustrates this exchange. 2164 Client Server 2165 v v 2166 | | 2167 |\_____________ | 2168 | RENEW \| 2169 | | 2170 | Extends lease 2171 | | 2172 | _____________/| 2173 |/ ACK | 2174 | | 2175 | | 2176 v v 2178 Figure 4: Timeline diagram of messages exchanged 2179 in Lease Extension example 2181 4. Address Release 2183 This is a continuation of the previous example. The client has 2184 already allocated a multicast address and extended its lease for 2185 another two hours. Half an hour later, the client finishes its use of 2186 the multicast address and wants to release it so it can be reused. 2188 The client unicasts a RELEASE packet to the server from which it 2189 allocated the address. This packet includes the Lease Identifier 2190 option. The Lease Identifier matches the one used for the original 2191 allocation. When the server receives this packet, it cancels the 2192 client's lease on the address and sends an ACK packet to the client 2193 indicating that the lease has been released. This packet includes the 2194 Server Identifier and Lease Identifier options. 2196 The following figure illustrates this exchange. 2198 Client Server 2199 v v 2200 | | 2201 |\_____________ | 2202 | RELEASE \| 2203 | | 2204 | Cancels lease 2205 | | 2206 | _____________/| 2207 |/ ACK | 2208 | | 2209 v v 2211 Figure 5: Timeline diagram of messages exchanged 2212 in Address Release example 2214 5. Unicast Address Allocation 2216 This is a continuation of the previous example. At some later time, 2217 the client decides to allocate another multicast address. Since it 2218 has recently worked with a server, it decides to try sending a 2219 unicast REQUEST to that server. If this doesn't work, it can always 2220 try a multicast DISCOVER, as illustrated in example 2. 2222 The client unicasts a REQUEST packet to the server from which it 2223 wants to allocate the address. This packet includes the Lease Time, 2224 Lease Identifier, and Multicast Scope options. 2226 The server responds with an ACK packet containing the Lease Time, 2227 Lease Identifier, and Multicast Scope options from the REQUEST 2228 packet, as well as the Server Identifier option and a List of Address 2229 Ranges option listing the address allocated. 2231 The client now has a lease on the multicast address. 2233 If the client had not received an ACK from the server, it would have 2234 retransmitted its REQUEST packet for a while. If it still received no 2235 response, it would start over with a multicast DISCOVER message. 2237 The following figure illustrates this exchange. 2239 Client Server 2240 v v 2241 | | 2242 |\_____________ | 2243 | REQUEST \| 2244 | | 2245 | Allocates address 2246 | | 2247 | _____________/| 2248 |/ ACK | 2249 | | 2250 v v 2252 Figure 6: Timeline diagram of messages exchanged 2253 in Unicast Address Allocation example 2255 APPENDIX B: Recommended Constant Values 2257 Table 6 lists recommended values for constants defined in this 2258 specification. 2260 Constant Name Recommended Value 2261 ------------- ----------------- 2262 [CLOCK-SKEW-ALLOWANCE] 30 minutes 2263 [DISCOVER-DELAY] current retransmit delay 2264 [EXTRA-ALLOCATION-TIME] 1 hour 2265 [NO-RESPONSE-DELAY] 60 seconds 2266 [OFFER-HOLD] 60 seconds 2267 [RESPONSE-CACHE-INTERVAL] 60 seconds (5 minutes maximum) 2268 [XID-REUSE-INTERVAL] 10 minutes 2270 Table 6: Recommended Constant Values