idnits 2.17.1 draft-hanna-marp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Address Type field indicates the type of addresses being requested. It is 0 for IPv4 multicast addresses and 1 for IPv6 multicast addresses. All other values are reserved. Clients MUST not send them and servers MUST ignore requests that contain them. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 4.1.1.2 Address Count (1 byte) The Address Count field indicates the number of addresses being requested. It may have any value from 1 to 255. The value 0 is reserved. Clients MUST not send it and servers MUST ignore requests that contain it. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Address Type field indicates the type of address being deallocated. It is 0 for IPv4 multicast addresses and 1 for IPv6 multicast addresses. All other values are reserved. Clients MUST not send them and servers MUST ignore requests that contain them. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Address Type field indicates the type of address whose interval is to be changed. It is 0 for IPv4 multicast addresses and 1 for IPv6 multicast addresses. All other values are reserved. Clients MUST not send them and servers MUST ignore requests that contain them. -- 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.) -- The document date (30 January 1998) is 9583 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-handley-malloc-arch - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-06) exists of draft-ietf-mboned-mzap-00 ** Downref: Normative reference to an Historic draft: draft-ietf-mboned-mzap (ref. '4') Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft S. Hanna 3 draft-hanna-marp-00.txt Sun Microsystems, Inc. 4 SML Document #98-0046 30 January 1998 5 Expires: 30 July 1998 7 Multicast Address Request Protocol (MARP) 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 The Multicast Address Request Protocol (MARP) serves as a front end 30 to the Multicast Address Allocation Architecture. Any host that 31 wishes to allocate a multicast address may contact a Multicast 32 Address Allocation Server and use MARP to request an address 33 allocation for a specific interval, scope, etc. Later, the host may 34 request an extension of the address allocation or deallocate the 35 address if it is no longer needed. 37 1 Introduction 39 Dynamically allocating multicast addresses on a global scale while 40 providing high reliability, low probability of clashes, good 41 utilization, and aggregation to reduce routing overhead is a 42 complicated matter. The Multicast Address Allocation Architecture 43 [1] describes a multicast address allocation system that meets these 44 requirements. 46 The Multicast Address Request Protocol (MARP) serves as a front end 47 to this multicast address allocation system. Any host that wishes to 48 allocate a multicast address may contact a Multicast Address 49 Allocation Server and use MARP to request an address allocation for a 50 specific lifetime, scope, etc. Later, the host may request an 51 extension of the address lifetime or deallocate the address if it is 52 no longer needed. 54 MARP plays the same role as MDHCP [2], but has certain advantages as 55 described in section 5. Basically, it is simpler and more efficient 56 because it doesn't have to maintain compatibility with DHCP. 58 This document is an initial proposal intended to stimulate debate. 59 There are still open issues, which are discussed in section 8. 61 1.1 Terminology 63 MARP is used by an IP host that wants to allocate an IP multicast 64 address from a pool of dynamically allocated addresses (or request 65 other multicast address allocation services). The host requesting 66 address allocation services is known as the "MARP client" or simply 67 "client" and the host supplying these services is known as the "MARP 68 server" or simply "server." 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC 2119. 74 2 Protocol Overview 76 All MARP packets are unicast UDP datagrams. There are three types of 77 MARP packets: requests, responses, and ACKs. When a MARP client 78 wishes to make a request, it sends a request packet to a MARP server. 79 In the simplest and most common case, the server responds with a 80 response packet and the client completes the exchange by sending an 81 ACK packet. Thus, a typical MARP exchange consists of three packets: 82 a request, a response, and an ACK. If packets are lost or a request 83 takes a long time to process, more packets may be required. 85 Requests and ACKs are sent to a reserved port on the server. For 86 now, port number 7342 should be used. If this document reaches RFC 87 status, a port number will be assigned by the IANA. Responses are 88 sent to the port and IP address from which the corresponding request 89 was received. 91 All MARP packets have a common format, described in section 3. The 92 packet type field is a single octet that marks the type of the 93 packet. While there are many possible values for this field (256, to 94 be exact), they are divided into ranges that allow any MARP client or 95 server to identify the packet and determine its appropriate behavior. 97 The ranges of packet types are: Request, Response - Permanent Error, 98 Response - Transient Error, Response - Success, Response - Progress 99 Report, ACK, and Reserved. The next few sections describe these types 100 and the appropriate behavior of a MARP client or server receiving a 101 packet with this type. For more information about specific types, see 102 section 4. 104 2.1 Requests 106 A request packet is sent by the client when it wants to initiate a 107 request. If no response is received for 10 seconds, the request 108 packet MAY be retransmitted. See section 2.5 for more details on 109 retransmitting requests. 111 Each request includes a sequence number assigned by the client, which 112 is included in each response or ACK that corresponds to that request 113 so that they may be matched with the request. The client MUST NOT 114 reuse a sequence number for at least 2 hours, as described in more 115 detail in section 3.5. 117 If a MARP server receives a request whose type it does not recognize 118 or cannot process and does not expect to ever do so, it MUST send 119 back a Cannot Process response (type 81, a Permanent Error). Servers 120 MUST support at least the Allocate Multicast Address request. 122 If a MARP client receives a request, it MUST ignore it. 124 2.2 Responses 126 A response packet is sent by a server to a client that has sent a 127 request. There are four kinds of responses: Response - Permanent 128 Error, Response - Transient Error, Response - Success, and Response - 129 Progress Report. The first three are called terminal responses. 131 There are generic and specific versions of each of these kinds. The 132 specific versions convey extra information (such as the reason for an 133 error or a multicast address for an Address Allocated response). 135 2.2.1 Sending Responses 137 There are three reasons to send a response packet: when a request is 138 completed (successfully or unsuccessfully), when a request is still 139 ongoing and more than 3 seconds has passed since the request was 140 received or the last response was sent (whichever is later), and when 141 a retransmitted request is received. 143 In the first case, a terminal response is sent. In the second case, a 144 progress report is sent. In the third case, the last response sent 145 (which may be terminal or not) is retransmitted. 147 To reiterate, after a request is completed, a MARP server MUST send a 148 terminal response to the client. After this, no more responses are 149 sent for this request (unless a retransmitted request is received). 151 If a request takes longer than 3 seconds to complete, the server MUST 152 send a Progress Report Response. This informs the client that the 153 request is still being processed. The Progress Report includes an 154 estimate of when the request will complete. If the request takes 155 longer than this estimate, the server MUST send another Progress 156 Report and continue this process until the request has completed, at 157 which time it MUST send a terminal response. 159 2.2.2 Handling Responses 161 If a MARP client receives a Permanent Error Response, it should 162 conclude that its request cannot be completed and this is a permanent 163 condition. The client MAY send the request to another MARP server. 164 It SHOULD NOT send the same request to the same server again to see 165 if the condition clears up. 167 If a MARP client receives a Transient Error Response, it should 168 conclude that its request cannot be completed, but this may be a 169 transient condition. The client MAY send the request to another MARP 170 server or it MAY send the same request to the same server again to 171 see if the condition clears up. If it sends the same request to the 172 same server, it SHOULD use an exponential backoff timer to avoid 173 swamping the server with the same request. 175 If a MARP client receives a Success Response, it should conclude that 176 its request was completed successfully. Certain request types should 177 result in only certain response types, which may include valuable 178 data. If such a request type was used and the response type is a 179 Success Response, but not one of those expected, the client SHOULD 180 behave as if a Permanent Error Response had been received. 182 If a MARP client receives a Progress Report, it MUST reset its 183 request retransmission timer to 10 seconds after the estimated 184 completion time included in the Progress Report. 186 If a MARP client receives a response whose specific type it does not 187 recognize, it MUST treat it as the generic version of its type (e.g. 188 an unrecognized type in the Response - Permanent Error range must be 189 treated as a Generic Permanent Error packet). MARP clients MAY only 190 recognize the generic responses. 192 If a MARP server receives a response, it MUST ignore it. 194 2.3 ACKs 195 A client MUST send an ACK packet when it receives a terminal response 196 packet. This informs the server that the client has received a 197 terminal response packet and the server MAY discard any state 198 corresponding to this request (such as entries in its request cache). 200 If a MARP server receives an ACK whose request sequence number it 201 does not recognize, it MUST ignore it. If a MARP client receives an 202 ACK, it MUST ignore it. 204 2.4 Reserved or Invalid Packets 206 If a MARP client or server receives a packet with a type in the 207 Reserved range or a packet that is otherwise invalid (too short, for 208 instance), it MUST ignore it. 210 2.5 Retransmitting Requests 212 To handle lost packets, the client SHOULD retransmit its request if 213 no response is heard for an interval of 10 seconds (or 10 seconds 214 after the estimated completion time included in a Progress Report). 215 If no response is heard to a request retransmission, the client MAY 216 retransmit its request up to 9 more times at 10 second intervals. At 217 any point during this process, the client MAY (and after the tenth 218 retransmission MUST) decide that the exchange has failed and send the 219 request to another server or abort the request. 221 The server MUST maintain a request cache (or equivalent) so that it 222 can recognize retransmitted requests and resend the most recent 223 response. Items in this cache MUST be retained for at least 120 224 seconds and no more than 2 hours after the terminal response is sent 225 (unless an ACK for an item is received, in which case the item MAY be 226 removed at that time). 228 A retransmitted request packet MUST be exactly the same as the 229 original. The server MUST check the source IP address, port, and 230 sequence number when recognizing retransmitted requests. When a 231 signature is present, this MUST also be checked. 233 2.6 Finding a MARP Server 235 Before it can send MARP requests, a MARP client must find a MARP 236 server. There are several ways that this can be done. 238 1) The DNS host name or IP address of the MARP server MAY be 239 statically configured or entered as a command line argument or via 240 some other means. 242 2) A DHCP server or some other dynamic configuration mechanism MAY be 243 employed to find the IP address or DNS host name of the MARP server. 245 3) The MARP client MAY monitor Address Allocation Protocol (AAP) [3] 246 messages on the multicast address used by AAP servers within the 247 scope zone from which an address is to be allocated and choose one of 248 the servers that are sending ADDRESS-IN-USE messages. 250 The third technique is preferred. If this method is used, the MARP 251 client SHOULD choose randomly among the AAP servers heard from. This 252 helps to avoid overloading the AAP servers. 254 2.7 Discovering Scopes 256 The set of scope zones in use may be statically configured or 257 discovered by monitoring MZAP [4] transmissions. Dynamic discovery is 258 more robust, but takes time. 260 A scope discovery message could be added to MARP, but it is important 261 to be sure the MARP server has the same set of scopes as the MARP 262 client and this is difficult to do without knowing what the scope 263 zones are (circular problem) or statically configuring the MARP 264 server address in the client (painful). 266 2.8 MARP Times 268 MARP packets contain a number of places where absolute times must be 269 represented. These time values are represented as unsigned 32-bit 270 integers in network byte order giving the number of seconds since 271 00:00 UTC, 1st January 1970. This is the same time value that is used 272 in the Address Allocation Protocol [3]. 274 Two special time values are defined. A time value of 0 (also known as 275 TIME_ASAP) means as early as possible. A time value of 2^32 - 1 (all 276 ones, also known as TIME_ALAP) means as late as possible. These 277 values are only allowed where explicitly stated. 279 If the clocks on the MARP client and MARP server are set differently, 280 problems can occur (like clients using addresses at the wrong time). 281 To prevent substantial clock skew, the MARP client includes its idea 282 of the current time in each Allocate Multicast Address request. If 283 this differs from the server's current time when the request is 284 received by more than 90 minutes, the server sends back a Clock Skew 285 Permanent Error. 287 To avoid problems caused by clock skew of less than 90 minutes (and 288 network delays), the MARP client SHOULD allocate addresses for at 289 least 2 hours earlier and 2 hours later than will be needed and let 290 the address sit idle for these hours. This will take care of two 291 clients that have almost 90 minutes of clock skew from the server in 292 opposite directions and one hour of network delays, multicast routing 293 latency, etc. 295 3 Generic Packet Format 297 All MARP packets are unicast UDP datagrams. Requests and ACKs are 298 sent to a reserved port on the server. Responses are sent to the port 299 and IP address from which the corresponding request was received. 301 All MARP packets share a common format, shown in Figure 1 (omitting 302 UDP headers). 304 0 1 2 3 4 5 6 7 305 +-+-+-+-+-+-+-+-+ 306 |Version| Flags | 307 +-+-+-+-+-+-+-+-+ 308 |Sec. Hdr. (opt)| 309 +-+-+-+-+-+-+-+-+ 310 | Type | 311 +-+-+-+-+-+-+-+-+ 312 | Request | 313 | Sequence Num. | 314 +-+-+-+-+-+-+-+-+ 315 | Data Length | 316 | (N) | 317 +-+-+-+-+-+-+-+-+ 318 | | 319 + Data + 320 ... 321 + (N bytes) + 322 | | 323 +-+-+-+-+-+-+-+-+ 325 Figure 1 327 3.1 Version (4 bits) 329 The Version field is always 0 for this version of MARP. If another 330 value is seen, the packet MUST be ignored. MARP should be extensible 331 enough so that the version need never be changed. New request and 332 response types may be added easily and handled properly by older 333 clients and servers that don't recognize them. 335 3.2 Flags (4 bits) 337 The most significant bit of the Flags field (marked 4 above) is the 338 Security bit (described in section 3.3, Security Header). The three 339 least significant bits MUST be sent as zero (0) and ignored on 340 reception. This allows for future extensions of the protocol in a 341 backward compatible fashion. 343 3.3 Security Header (variable length) 345 If the Security bit in the Flags field is set to 1, a Security Header 346 appears after the Flags field. The format of the Security Header is 347 shown in Figure 2. 349 0 1 2 3 4 5 6 7 350 +-+-+-+-+-+-+-+-+ 351 | Sig. Type | 352 +-+-+-+-+-+-+-+-+ 353 | Sig. Length | 354 | (SL) | 355 +-+-+-+-+-+-+-+-+ 356 | | 357 + Sig. Data + 358 ... 359 + (SL bytes) + 360 | | 361 +-+-+-+-+-+-+-+-+ 362 | Encr. Type | 363 +-+-+-+-+-+-+-+-+ 364 | Encr. Length | 365 | (EL) | 366 +-+-+-+-+-+-+-+-+ 367 | | 368 + Encr. Data + 369 ... 370 + (EL bytes) + 371 | | 372 +-+-+-+-+-+-+-+-+ 374 Figure 2 376 3.3.1 Signature 378 If the Signature Type field is zero, no digital signature is included 379 in this packet. The Signature Length field must be zero and the 380 Signature Data field must be omitted. 382 Otherwise, the Signature Type field identifies the type of digital 383 signature used. The Signature Data field includes the digital 384 signature of all bytes in the packet after the Signature Data field. 385 The Signature Length field includes the number of bytes of data in 386 the Signature Data field. 388 If a MARP server receives a packet whose Signature Type field it does 389 not support, it MUST send back a Signature Type Not Supported 390 Permanent Error packet. If it supports the Signature Type but cannot 391 verify the signature, it SHOULD send back a Signature Not Verified 392 Permanent Error packet. However, if the packet also uses encryption 393 and cannot be decrypted, the decryption errors described in section 394 3.3.2 MUST be sent instead. 396 If a MARP server receives a request whose Signature Type field it 397 supports, it SHOULD use the same Signature Type in its response since 398 the MARP client clearly supports this Signature Type. 400 If a MARP client receives a packet whose signature it cannot verify, 401 it SHOULD ignore it. 403 MARP servers and clients MAY be configured to support any set of 404 signature types, based on administrative decisions. 406 3.3.1.1 DSA Signature 408 A packet whose Signature Type is 1 is signed with DSA (Digital Signature 409 Standard). The Signature Data field contains the name associated with 410 the private key used to sign the data and the signature itself. No 411 certificates are included with this type of signature. The recipient is 412 expected to have access to a public key infrastructure or other 413 mechanism for finding and verifying the public key associated with a 414 name. 416 3.3.2 Encryption 418 If the Encryption Type field is zero, encryption is not used on this 419 packet. The Encryption Length field must be zero and the Encryption 420 Data field must be omitted. 422 Otherwise, the Encryption Type field identifies the type of encryption 423 used. The Encryption Data field includes data which is specific to the 424 encryption method used. The Encryption Length field includes the number 425 of bytes of data in the Encryption Data field. All bytes in the packet 426 after the Encryption Data field are ciphertext (including the Type and 427 Request Sequence Number). 429 If a MARP server receives a packet whose Encryption Type field it does 430 not support, it MUST send back a Encryption Type Not Supported Permanent 431 Error packet. Since it cannot decrypt the packet, it cannot read its 432 Type or Request Sequence Number fields. It MUST use sequence number 0 in 433 its response and MUST NOT cache this response. 435 If a MARP server receives a packet whose Encryption Type field it 436 supports but which it cannot decrypt, it MUST send back a Decryption 437 Failed Permanent Error packet. Since it cannot decrypt the packet, it 438 cannot read its type or request sequence number. It MUST use sequence 439 number 0 in its response and MUST NOT cache this response. 441 If a MARP server receives a request whose Encryption Type field it 442 supports, it SHOULD use the same Encryption Type in its response since 443 the MARP client clearly supports this Encryption Type. 445 If a MARP client receives a packet whose Encryption Type field it does 446 not support or which it cannot decrypt, it MUST ignore the packet. 448 MARP servers and clients MAY be configured to support any set of 449 encryption types, based on administrative decisions. 451 3.3.2.1 Triple DES Encryption 453 A packet whose Encryption Type is 1 is encrypted with Triple DES (DES- 454 EDE as per spec - 168 bit key derived from 192) using a key that is 455 randomly selected by the MARP client on a per-request basis (called the 456 request key). For requests, the request key is encrypted with the public 457 key of the MARP server and included in the Encryption Data field. For 458 responses and ACKs, the same key is used, but it is not transmitted in 459 the response or ACK packet. 461 Cipher Block Chaining (CBC) is used with a 64 bit (8 byte) 462 initialization vector (IV) chosen randomly by the client and included in 463 the Encryption Data field. The same IV is used in a response or ACK, but 464 not transmitted in the response or ACK packet. 466 Because DES-3EDE-CBC requires the length of the plaintext to be a 467 multiple of 64 bits (8 bytes), padding is added to the plaintext as 468 necessary until it reaches such a length. The number of pad bytes added 469 is included in the Encryption Data field so that they may be stripped 470 off after decryption. The pad bytes have values 1, 2, 3, and so forth 471 (up to a maximum of 7) until the plaintext reaches a multiple of 8 472 bytes. 474 In a request packet, the Encryption Data field contains the request key 475 (encrypted with the public key of the server) followed by the name that 476 is associated with the server's public key (preceded by a length byte), 477 the IV, and a single byte with the number of pad bytes. In a response or 478 ACK packet, the Encryption Data field contains the number of pad bytes 479 and the Encryption Length field is 1. 481 3.4 Type (1 byte) 483 The Type field indicates what type of MARP packet this is. There are 484 several ranges of type values so that more types may be defined in the 485 future and older implementations will be able to respond in a well- 486 defined manner. These ranges are listed in Figure 3 and described in 487 more detail in sections 2 and 4. 489 Type Range Meaning 490 ---------- ------- 491 00 - 3f Request 492 40 - 7f Response - Success 493 80 - 9f Response - Permanent Error 494 a0 - bf Response - Transient Error 495 c0 - df Response - Progress Report 496 e0 ACK 497 e1 - ff Reserved 499 Figure 3 501 3.5 Request Sequence Number (2 bytes) 503 The request sequence number is a 2 octet number chosen by the MARP 504 client and sent in the initial request packet. The same sequence 505 number is included in each response, ACK, or retransmitted request 506 that corresponds to the initial request. 508 The sequence number 0 MUST NOT be sent in a request, since the MARP 509 server uses this value for responding to encrypted packets that it 510 could not decrypt and whose sequence number it therefore could not 511 read. 513 It is undesirable to have the same sequence number used for two 514 different requests from the same source IP address and port within a 515 few hours, as packets from the old request may be hanging around the 516 network or (within a few minutes) the server's request cache. 518 Therefore, a MARP client MUST NOT reuse a request sequence number 519 with the same source IP address and port within 2 hours of the 520 initial request. Also, a MARP client SHOULD choose its request 521 sequence numbers in such a way that it is unlikely that another MARP 522 client with the same source IP address and port used the same 523 sequence number within the past 2 hours. 525 One simple way to do this is to choose the initial sequence number 526 randomly, then increment it for subsequent requests from the same 527 client. As long as the client is not sending more than 32,768 528 requests per hour there will be no problem. 530 3.6 Data Length and Data 531 The Data Length field is an unsigned two octet number in network byte 532 order that specifies how many bytes of data are included in the 533 packet. This field is followed by the specified number of bytes of 534 data. The meaning of the data depends on the packet type. 536 4 Specific Packet Types 538 This section describes the meaning of specific values of the Type 539 field in a MARP packet. 541 4.1 Requests 543 4.1.1 Allocate Multicast Address (type 00) 545 The Allocate Multicast Address request asks the MARP server to 546 allocate a multicast address. If the request succeeds, a Multicast 547 Address Allocation Success response MUST be returned. If the request 548 fails because no addresses are available that would satisfy the 549 request, the No Addresses Available Transient Error response SHOULD 550 be returned. 552 The Data Length varies depending on the address type. The format of 553 the data is shown in Figure 4. 555 If an Allocate Multicast Address request is signed, the MARP server 556 SHOULD remember the identity that signed it so that it may use this 557 information to control who may deallocate the address or change its 558 interval. 560 To avoid malicious users allocating all the addresses on a MARP 561 server, several techniques may be employed. The MARP server MAY limit 562 the number of addresses that may be allocated in an hour. It MAY 563 limit address allocation based on identity (as verified by 564 signature). Both of these are good techniques. 566 If a MARP server limits address allocation based on identity, it 567 SHOULD cache requests for at least two hours to avoid replay attacks 568 (replaying an authorized allocation request to use up someone's 569 allocation). 571 0 1 2 3 4 5 6 7 572 +-+-+-+-+-+-+-+-+ 573 | Address Type | 574 +-+-+-+-+-+-+-+-+ 575 | Address Count | 576 +-+-+-+-+-+-+-+-+ 577 | | 578 + Scope + 579 ... 580 + (size varies + 581 |with addr type)| 582 +-+-+-+-+-+-+-+-+ 583 | Current | 584 | Time | 585 | | 586 | | 587 +-+-+-+-+-+-+-+-+ 588 | Requested | 589 | Address | 590 | Start | 591 | Time | 592 +-+-+-+-+-+-+-+-+ 593 | Requested | 594 | Address | 595 | End | 596 | Time | 597 +-+-+-+-+-+-+-+-+ 598 | Required | 599 | Address | 600 | Start | 601 | Time | 602 +-+-+-+-+-+-+-+-+ 603 | Required | 604 | Address | 605 | End | 606 | Time | 607 +-+-+-+-+-+-+-+-+ 609 Figure 4 611 4.1.1.1 Address Type (1 byte) 613 The Address Type field indicates the type of addresses being 614 requested. It is 0 for IPv4 multicast addresses and 1 for IPv6 615 multicast addresses. All other values are reserved. Clients MUST not 616 send them and servers MUST ignore requests that contain them. 618 4.1.1.2 Address Count (1 byte) 619 The Address Count field indicates the number of addresses being 620 requested. It may have any value from 1 to 255. The value 0 is 621 reserved. Clients MUST not send it and servers MUST ignore requests 622 that contain it. 624 4.1.1.3 Scope (variable length) 626 The Scope field is the first IP address in the scope zone from which 627 the address must be allocated. The length of the Scope field is 4 if 628 the Address Type field is 0 and 16 if the Address Type field is 1. 630 If the Scope field is all 0s, global scope is implied. The MARP 631 server and client must both be in the scope zone requested. This is 632 guaranteed if the client uses AAP to find MARP servers. 634 4.1.1.4 Current Time (4 bytes) 636 The Current Time is the client's idea of the current time when the 637 request was first made. This value does not change when a request is 638 retransmitted, so it may be a few minutes old when received by the 639 server. Neither 0 (TIME_ASAP) nor 2^32 - 1 (TIME_ALAP) are valid 640 here. 642 If a MARP server receives an Allocate Multicast Address request that 643 includes a current time that differs from its own by more than 90 644 minutes, it MUST return a Clock Skew Permanent Error response. This 645 avoids misunderstandings caused by substantial clock skew. If a MARP 646 server caches requests for two hours, this will also prevent replay 647 attacks. 649 4.1.1.5 Requested Address Start Time (4 bytes) 651 The Requested Address Start Time is the time at which the client 652 would like the allocation to start. This is a MARP time, as described 653 in section 2.7. A time value of 0 (TIME_ASAP) is valid here, but 2^32 654 - 1 (TIME_ALAP) is not. 656 4.1.1.6 Requested Address End Time (4 bytes) 658 The Requested Address End Time is the time at which the client would 659 like the allocation to end. This is a MARP time, as described in 660 section 2.7. This value MUST be greater than the requested address 661 start time. A time value of 2^32 - 1 (TIME_ALAP) is valid here, but 662 0 (TIME_ASAP) is not. 664 4.1.1.7 Required Address Start Time (4 bytes) 666 The Required Address Start Time is the latest time that the client is 667 willing to accept as an address start time. If the server cannot 668 supply an address whose start time is at least this early, it MUST 669 send a failure response. This is a MARP time, as described in section 670 2.7. A time value of 0 (TIME_ASAP) is valid here, but 2^32 - 1 671 (TIME_ALAP) is not. TIME_ASAP here means that only a time value of 672 TIME_ASAP may be returned. 674 4.1.1.8 Required Address End Time (4 bytes) 676 The Required Address End Time is the earliest time that the client is 677 willing to accept as an address end time. If the server cannot supply 678 an address whose end time is at least this late, it MUST send a 679 failure response. This is a MARP time, as described in section 2.7. 680 This value MUST be greater than the required address start time. 681 Neither 0 (TIME_ASAP) nor 2^32 - 1 (TIME_ALAP) are valid here. 683 4.1.2 Deallocate Multicast Address (type 01) 685 The Deallocate Multicast Address request asks the MARP server to 686 deallocate a multicast address. If the request succeeds, a Generic 687 Success response MUST be returned. 689 The Data Length varies depending on the address type. The format of 690 the data is shown in Figure 5. 692 It is strongly suggested that MARP servers require Deallocate 693 Multicast Address requests to be signed and make sure that they are 694 signed by an identity with permission to deallocate the address (such 695 as the same identity that allocated the address). Otherwise, 696 malicious users may change the interval of addresses allocated by 697 others. 699 0 1 2 3 4 5 6 7 700 +-+-+-+-+-+-+-+-+ 701 | Address Type | 702 +-+-+-+-+-+-+-+-+ 703 | Allocated | 704 + Address + 705 ... 706 + (size varies + 707 |with addr type)| 708 +-+-+-+-+-+-+-+-+ 709 | Address | 710 | Start | 711 | Time | 712 | | 713 +-+-+-+-+-+-+-+-+ 714 | Address | 715 | End | 716 | Time | 717 | | 718 +-+-+-+-+-+-+-+-+ 720 Figure 5 722 4.1.2.1 Address Type (1 byte) 724 The Address Type field indicates the type of address being 725 deallocated. It is 0 for IPv4 multicast addresses and 1 for IPv6 726 multicast addresses. All other values are reserved. Clients MUST not 727 send them and servers MUST ignore requests that contain them. 729 4.1.2.2 Allocated Address (variable length) 731 The Allocated Address field is the address being deallocated. The 732 length of the Allocated Address field is 4 if the Address Type field 733 is 0 and 16 if the Address Type field is 1. 735 4.1.2.2 Address Start Time (4 bytes) 737 The Address Start Time is the address start time for this address. 738 It MUST match the value included in the most recent Multicast Address 739 Allocation Success Response or Change Address Interval Success 740 Response sent by the server for this address. A MARP server MAY omit 741 checking this value if it does not allocate a given address more than 742 once for different intervals. The time value 0 (TIME_ASAP) is valid 743 here, but 2^32 - 1 (TIME_ALAP) is not. 745 4.1.2.3 Address End Time (4 bytes) 746 The Address End Time is the address end time for this address. It 747 MUST match the value included in the most recent Multicast Address 748 Allocation Success Response or Change Address Interval Success 749 Response sent by the server for this address. A MARP server MAY omit 750 checking this value if it does not allocate a given address more than 751 once for different intervals. Neither 0 (TIME_ASAP) nor 2^32 - 1 752 (TIME_ALAP) is valid here. 754 4.1.3 Change Interval (type 02) 756 The Change Interval request asks the MARP server to change the start 757 and end time of a multicast address that has already been allocated 758 with this MARP server. If the request succeeds, a Change Interval 759 Success response MUST be returned. If the request fails, the address 760 remains allocated with the old interval. 762 It is strongly suggested that MARP servers require Change Interval 763 requests to be signed and make sure that they are signed by an 764 identity with permission to change the interval of the address (such 765 as the same identity that allocated the address). Otherwise, 766 malicious users may change the interval of addresses allocated by 767 others. 769 The Data Length varies depending on the address type. The format of 770 the data is shown in Figure 6. 772 0 1 2 3 4 5 6 7 773 +-+-+-+-+-+-+-+-+ 774 | Address Type | 775 +-+-+-+-+-+-+-+-+ 776 | Allocated | 777 + Address + 778 ... 779 + (size varies + 780 |with addr type)| 781 +-+-+-+-+-+-+-+-+ 782 | Address | 783 | Start | 784 | Time | 785 | | 786 +-+-+-+-+-+-+-+-+ 787 | Address | 788 | End | 789 | Time | 790 | | 791 +-+-+-+-+-+-+-+-+ 792 | Requested | 793 | Address | 794 | Start | 795 | Time | 796 +-+-+-+-+-+-+-+-+ 797 | Requested | 798 | Address | 799 | End | 800 | Time | 801 +-+-+-+-+-+-+-+-+ 802 | Required | 803 | Address | 804 | Start | 805 | Time | 806 +-+-+-+-+-+-+-+-+ 807 | Required | 808 | Address | 809 | End | 810 | Time | 811 +-+-+-+-+-+-+-+-+ 813 Figure 6 815 4.1.3.1 Address Type (1 byte) 817 The Address Type field indicates the type of address whose interval 818 is to be changed. It is 0 for IPv4 multicast addresses and 1 for 819 IPv6 multicast addresses. All other values are reserved. Clients 820 MUST not send them and servers MUST ignore requests that contain 821 them. 823 4.1.3.2 Allocated Address (variable length) 825 The Allocated Address field is the address whose interval is to be 826 changed. The length of the Allocated Address field is 4 if the 827 Address Type field is 0 and 16 if the Address Type field is 1. 829 4.1.3.3 Address Start Time (4 bytes) 831 The Address Start Time is the address start time for this address. 832 It MUST match the value included in the most recent Multicast Address 833 Allocation Success Response or Change Address Interval Success 834 Response sent by the server for this address. A MARP server MAY omit 835 checking this value if it does not allocate a given address more than 836 once for different intervals. The time value 0 (TIME_ASAP) is valid 837 here, but 2^32 - 1 (TIME_ALAP) is not. 839 4.1.3.4 Address End Time (4 bytes) 841 The Address End Time is the address end time for this address. It 842 MUST match the value included in the most recent Multicast Address 843 Allocation Success Response or Change Address Interval Success 844 Response sent by the server for this address. A MARP server MAY omit 845 checking this value if it does not allocate a given address more than 846 once for different intervals. Neither 0 (TIME_ASAP) nor 2^32 - 1 847 (TIME_ALAP) is valid here. 849 4.1.3.5 Requested Address Start Time (4 bytes) 851 The Requested Address Start Time is the time at which the client 852 would like to start using the address. This is a MARP time, as 853 described in section 2.7. A time value of 0 (TIME_ASAP) is valid 854 here, but 2^32 - 1 (TIME_ALAP) is not. 856 4.1.3.6 Requested Address End Time (4 bytes) 858 The Requested Address End Time is the time at which the client would 859 like to stop using the address. This is a MARP time, as described in 860 section 2.7. This value MUST be greater than the requested address 861 start time. A time value of 2^32 - 1 (TIME_ALAP) is valid here, but 862 0 (TIME_ASAP) is not. 864 4.1.3.7 Required Address Start Time (4 bytes) 866 The Required Address Start Time is the latest time that the client is 867 willing to accept as an address start time. If the server cannot 868 supply an address whose start time is at least this early, it MUST 869 send a failure response. However, the address MUST remain allocated 870 with the old interval. This is a MARP time, as described in section 871 2.7. A time value of 0 (TIME_ASAP) is valid here, but 2^32 - 1 872 (TIME_ALAP) is not. TIME_ASAP here means that only a time value of 873 TIME_ASAP may be returned. 875 4.1.3.8 Required Address End Time (4 bytes) 877 The Required Address End Time is the earliest time that the client is 878 willing to accept as an address end time. If the server cannot supply 879 an address whose end time is at least this late, it MUST send a 880 failure response. However, the address MUST remain allocated with the 881 old interval. This is a MARP time, as described in section 2.7. This 882 value MUST be greater than the required address start time. Neither 883 0 (TIME_ASAP) nor 2^32 - 1 (TIME_ALAP) are valid here. 885 4.2 Responses 887 This section describes the meaning of specific responses. For a 888 description of how to handle responses in general, see section 2.2.2. 890 4.2.1 Generic Success (type 40) 892 The Generic Success response indicates that a request completed 893 successfully. No data is included. 895 4.2.2 Multicast Address Allocation Success (type 41) 897 The Multicast Address Allocation Success response indicates that an 898 Allocate Multicast Address request completed successfully. The data 899 contains the addresses allocated and the interval during which they 900 are allocated. 902 The Data Length varies depending on the address type (given in the 903 request). The format of the data is shown in Figure 7. 905 The MARP server does not have to return the number of addresses 906 requested. It MAY return any number of addresses from 1 to the 907 number requested in a Multicast Address Allocation Success Response. 908 However, it MUST NOT return more addresses than requested. 910 The addresses returned do not have to be contiguous, although they 911 may be. There is no way for a MARP client to request contiguous 912 addresses or to request that a specific multicast address be 913 allocated. MARP clients SHOULD NOT assume or attempt to achieve such 914 conditions. 916 0 1 2 3 4 5 6 7 917 +-+-+-+-+-+-+-+-+ 918 | Address | 919 | Start | 920 | Time | 921 | | 922 +-+-+-+-+-+-+-+-+ 923 | Address | 924 | End | 925 | Time | 926 | | 927 +-+-+-+-+-+-+-+-+ 928 | Address Count | 929 +-+-+-+-+-+-+-+-+ 930 | Allocated | 931 + Addresses + 932 ... 933 + (size varies + 934 |with addr type)| 935 +-+-+-+-+-+-+-+-+ 937 Figure 7 939 4.2.2.1 Address Start Time (4 bytes) 941 The Address Start Time is the time at which the client MAY start 942 using the allocated addresses. This is a MARP time, as described in 943 section 2.7. A time value of 0 (TIME_ASAP) is valid here, but 2^32 - 944 1 (TIME_ALAP) is not. TIME_ASAP means that the addresses may be used 945 immediately. The MARP server SHOULD return TIME_ASAP instead of the 946 current time, as this value removes any confusion caused by clock 947 skew. 949 4.2.2.2 Address End Time (4 bytes) 951 The Address End Time is the time at which the client MUST stop using 952 the allocated addresses. This is a MARP time, as described in section 953 2.7. Neither 0 (TIME_ASAP) nor 2^32 - 1 (TIME_ALAP) is valid here. 955 4.2.2.3 Address Count (1 byte) 957 The Address Count is the number of addresses that the MARP server has 958 allocated. 960 4.2.2.4 Allocated Addresses (variable length) 962 The Allocated Addresses field contains the addresses that have been 963 allocated. The length of each address is 4 if the address type 964 specified in the request is 0 (IPv4 addresses) and 16 if the address 965 type is 1 (IPv6 addresses). 967 4.2.3 Change Interval Success (type 42) 969 The Change Interval Success response indicates that a Change Interval 970 request completed successfully. The data contains the new interval 971 during which the address is allocated. 973 The Data Length is always 8. The format of the data is shown in 974 Figure 8. 976 0 1 2 3 4 5 6 7 977 +-+-+-+-+-+-+-+-+ 978 | Address | 979 | Start | 980 | Time | 981 | | 982 +-+-+-+-+-+-+-+-+ 983 | Address | 984 | End | 985 | Time | 986 | | 987 +-+-+-+-+-+-+-+-+ 989 Figure 8 991 4.2.3.1 Address Start Time (4 bytes) 993 The Address Start Time is the time at which the client may start 994 using the allocated address. This is a MARP time, as described in 995 section 2.7. A time value of 0 (TIME_ASAP) is valid here, but 2^32 - 996 1 (TIME_ALAP) is not. TIME_ASAP means that the address may be used 997 immediately. The MARP server SHOULD return TIME_ASAP instead of the 998 current time, as this value removes any confusion caused by clock 999 skew. 1001 4.2.3.2 Address End Time (4 bytes) 1003 The Address End Time is the time at which the client may stop using 1004 the allocated address. This is a MARP time, as described in section 1005 2.7. Neither 0 (TIME_ASAP) nor 2^32 - 1 (TIME_ALAP) is valid here. 1007 4.2.4 Generic Permanent Error (type 80) 1009 The Generic Permanent Error response indicates that a request cannot 1010 be completed and this is a permanent condition. No data is included. 1011 For a description of how to handle this response, see section 2.2.2. 1013 4.2.5 Cannot Process Permanent Error (type 81) 1015 The Cannot Process Permanent Error response indicates that a request 1016 cannot be processed because it is unrecognized or unsupported and 1017 this is a permanent condition. No data is included. For a 1018 description of how to handle this response, see section 2.2.2. 1020 4.2.6 Encryption Type Not Supported Permanent Error (type 82) 1022 The Encryption Type Not Supported Permanent Error response indicates 1023 that a packet cannot be processed because the MARP server does not 1024 support the value in the Encryption Type field. Since the MARP server 1025 cannot decrypt the packet, it cannot read its Type or Request 1026 Sequence Number fields. It MUST use sequence number 0 in its response 1027 and MUST NOT cache this response. 1029 The data contains a list of supported encryption types and as much of 1030 the original packet as will fit in a single UDP packet. The MARP 1031 client MAY decrypt this packet to recognize which request failed and 1032 try sending it again with a different encryption type. 1034 The format of the data is shown in Figure 9. 1036 0 1 2 3 4 5 6 7 1037 +-+-+-+-+-+-+-+-+ 1038 | E. Type Count | 1039 +-+-+-+-+-+-+-+-+ 1040 | Sptd. Enc. | 1041 + Types + 1042 ... 1043 + (ETC bytes) + 1044 | | 1045 +-+-+-+-+-+-+-+-+ 1046 | Pkt Data Len | 1047 | (PDL) | 1048 +-+-+-+-+-+-+-+-+ 1049 | Packet | 1050 + Data + 1051 ... 1052 + (PDL bytes) + 1053 | | 1054 +-+-+-+-+-+-+-+-+ 1056 Figure 9 1058 4.2.6.1 Encryption Type Count (1 byte) 1060 The Encryption Type Count field is a one octet unsigned number 1061 indicating how many supported encryption types are included in the 1062 Supported Encryption Types field. Since each entry in this list is 1 1063 byte long, this value is also the length of that field in bytes. 1065 4.2.6.2 Supported Encryption Types (variable length) 1067 The Supported Encryption Types field is a series of one octet numbers 1068 indicating which encryption types are supported by the MARP server. 1069 These numbers need not be sorted in any way, although they should not 1070 include duplicates. 1072 4.2.6.3 Packet Data Length (2 bytes) 1074 The Packet Data Length field is a two octet unsigned number giving 1075 the length of the following Packet Data field in bytes. 1077 4.2.6.4 Packet Data (variable length) 1079 The Packet Data field contains as much of the packet that could not 1080 be decrypted as will fit into the response. This data starts with the 1081 Version field, thus skipping the UDP header of the original packet. 1083 4.2.7 Decryption Failed Permanent Error (type 83) 1085 The Decryption Failed Permanent Error response indicates that a 1086 packet cannot be processed because the MARP server supports the value 1087 in the Encryption Type field but was unable to decrypt the packet. 1088 Since the MARP server cannot decrypt the packet, it cannot read its 1089 Type or Request Sequence Number fields. It MUST use sequence number 0 1090 in its response and MUST NOT cache this response. 1092 The data contains the complete contents of the original packet 1093 (although the end of the packet may need to be clipped in order to 1094 fit in a single UDP packet). The MARP client MAY verify that it sent 1095 this packet and decrypt it to recognize which request failed and what 1096 the problem was. 1098 4.2.8 Signature Type Not Supported Permanent Error (type 84) 1100 The Signature Type Not Supported Permanent Error response indicates 1101 that a packet cannot be processed because the MARP server does not 1102 support the value in the Signature Type field. No data is included. 1103 For a description of how to handle this response, see section 2.2.2. 1105 The data contains a list of supported signature types. The format of 1106 the data is shown in Figure 10. 1108 0 1 2 3 4 5 6 7 1109 +-+-+-+-+-+-+-+-+ 1110 | S. Type Count | 1111 +-+-+-+-+-+-+-+-+ 1112 | Sptd. Sig. | 1113 + Types + 1114 ... 1115 + (STC bytes) + 1116 | | 1117 +-+-+-+-+-+-+-+-+ 1119 Figure 10 1121 4.2.8.1 Signature Type Count (1 byte) 1123 The Signature Type Count field is a one octet unsigned number 1124 indicating how many supported signature types are included in the 1125 Supported Signature Types field. Since each entry in this list is 1 1126 byte long, this value is also the length of that field in bytes. 1128 4.2.8.2 Supported Signature Types (variable length) 1130 The Supported Signature Types field is a series of one octet numbers 1131 indicating which signature types are supported by the MARP server. 1132 These numbers need not be sorted in any way, although they should not 1133 include duplicates. 1135 4.2.9 Signature Not Verified Permanent Error (type 85) 1137 The Signature Not Verified Permanent Error response indicates that a 1138 packet cannot be processed because the MARP server supports the value 1139 in the Signature Type field, but could not verify the signature. No 1140 data is included. For a description of how to handle this response, 1141 see section 2.2.2. 1143 4.2.10 Clock Skew Permanent Error (type 86) 1145 The Clock Skew Permanent Error response indicates that the current 1146 time supplied by the client differs from that maintained by the 1147 server by more than 90 minutes. The current time included in the 1148 packet and the server's idea of the current time are included in the 1149 data. 1151 It is suggested that the MARP client log an error noting these values 1152 along with the server identity or IP address. It is not suggested 1153 that the MARP client adjust its clock automatically, since the server 1154 clock may in fact be in error. In any case, the client SHOULD NOT 1155 send any more requests to this server until the clock skew problem is 1156 addressed. 1158 The Data Length is always 8. The format of the data is shown in 1159 Figure 11. 1161 0 1 2 3 4 5 6 7 1162 +-+-+-+-+-+-+-+-+ 1163 | Client | 1164 | Current | 1165 | Time | 1166 | | 1167 +-+-+-+-+-+-+-+-+ 1168 | Server | 1169 | Current | 1170 | Time | 1171 | | 1172 +-+-+-+-+-+-+-+-+ 1174 Figure 11 1176 4.2.11 Generic Transient Error (type a0) 1178 The Generic Transient Error response indicates that a request cannot 1179 be completed, but this may be a transient condition. No data is 1180 included. For a description of how to handle this response, see 1181 section 2.2.2. 1183 4.2.12 No Addresses Available Transient Error (type a1) 1185 The No Addresses Available Transient Error response indicates that no 1186 addresses were available that would satisfy a request. This response 1187 is sent if no addresses are available that satisfy an Allocate 1188 Multicast Address request, for instance. No data is included. For a 1189 description of how to handle this response, see section 2.2.2. 1191 4.2.13 Generic Progress Report (type c0) 1193 The Generic Success response indicates that a request is still being 1194 processed. The data contains an estimated completion time. 1196 The Data Length is always 4. The format of the data is shown in 1197 Figure 12. 1199 0 1 2 3 4 5 6 7 1200 +-+-+-+-+-+-+-+-+ 1201 | Estimated | 1202 | Completion | 1203 | Time | 1204 | | 1205 +-+-+-+-+-+-+-+-+ 1207 Figure 12 1209 4.2.13.1 Estimated Completion Time (4 bytes) 1211 The Estimated Completion Time is an estimate of when the request will 1212 be completed. It is an unsigned 32-bit number of seconds from the 1213 time the progress report is sent. It is NOT a MARP time. See section 1214 2 for descriptions of how this time is used by the client. 1216 5 Comparison with MDHCP 1218 Because MDHCP is based on DHCP, it includes several features that 1219 were required for DHCP's problem set but are not required for 1220 multicast address allocation. For instance, compatibility with BOOTP 1221 forwarders. 1223 MDHCP requires the presence of a DHCP server to get the MDHCP server 1224 multicast address and multicast scope list (or static configuration). 1225 MARP uses AAP to find servers, therefore avoiding lots of extra 1226 complexity. 1228 A different version of MDHCP will be required to support IPv6. MARP 1229 supports both IPv4 and IPv6. 1231 MDHCP uses the same port number as DHCP on the server, so it will not 1232 be possible to colocate an MDHCP and DHCP server unless they are the 1233 same process. MARP does not have this problem. 1235 Security is crucial for multicast address allocation, but MDHCP does 1236 not include support for security. It refers to ongoing DHCP security 1237 work, but this is not complete. MARP includes security support. 1239 MDHCP uses a single multicast address for all MDHCP servers. This 1240 may cause problems when there are different multicast scopes. 1242 MDHCP requires two multicast packets and two unicast packets for a 1243 protocol exchange. MARP requires only three unicast packets. 1245 MDHCP does not include support for a requested interval, just a 1246 required one. 1248 MDHCP may be able to leverage some code from DHCP servers. 1250 6 Security Considerations 1252 Authenticating the MARP client allows for per-user limits on address 1253 allocation and charging for addresses (if desired), and prevents 1254 deallocating someone else's address. 1256 Authenticating the MARP server prevents creating a fake MARP server 1257 that gives out invalid addresses. 1259 Caching requests for 2 hours and rejecting requests with a current 1260 time that differs from the servers by more than 90 minutes prevents 1261 replay attacks (assuming authentication is required). 1263 Encryption is somewhat useful, but probably not essential. Knowing 1264 who is requesting multicast address allocation services and what the 1265 response is might make it easier for attackers to jam multicast 1266 sessions. Or simply learning who's doing what might be interesting. 1268 IPsec or TLS could be used for this application, but IPsec currently 1269 does not support different security associations for different 1270 processes on a single machine and TLS would require lots more 1271 overhead per request. 1273 7 References 1275 [1] Handley, M., Thaler, D., and D. Estrin, "The Internet Multicast Address 1276 Allocation Architecture", draft-handley-malloc-arch-00.txt, Internet 1277 Draft, December 1997. 1279 [2] Patel, B. and M. Shah, "Multicast address allocation extensions to the 1280 Dynamic Host Configuration Protocol", draft-ietf-dhc-mdhcp-03.txt, 1281 Internet Draft, November 1997. 1283 [3] Handley, M., "Multicast Address Allocation Protocol", 1284 draft-handley-aap-00.txt, Internet Draft, December 1997. 1286 [4] Handley, M., "Multicast Scope Zone Announcement Protocol", 1287 draft-ietf-mboned-mzap-00.txt, December 1997. 1289 8 Open Issues 1291 * We need a reserved port number for the MARP server. 1293 * Do we need to support future allocation (where the server returns a 1294 token instead of an address)? We could use a new address type for this. 1296 * We should change AAP so that AAP servers that are willing 1297 to act as a MARP server send some sort of periodic message when they 1298 don't have any addresses in use. This is excess multicast traffic, 1299 but it's no worse than AAP in its stable state. 1301 9 Author's Address 1303 Steve Hanna 1304 Sun Microsystems, Inc. 1305 2 Elizabeth Drive M/S CHL03-205 1306 Chelmsford, MA 01824 1308 Tel: +1.978.442.0166 1309 Fax: +1.978.250.5067 1310 Email: steve.hanna@sun.com